file(1) Magdir candidate: wintendo
Hi folks, I've had some interesting comments from David Bushong, motivating for inclusion of his Magdir candidate on PR 12554. He makes a strong case for a bloated file(1) Magdir. The only thing we're battling with is a filename for his submission. Just because a bloated file(1) magic database is good, doesn't mean we want a zillion files in the Magdir source, though. So I propose a new file wintendo, for all gaming file formats used on the MS Windows platform. Sensible objections? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
Another cool attack on this mechanism is if the binary uses shared libraries: modify LD_LIBRARY_PATH so that its favorite shared library is your own version of the library, that proceeds to dump the entire application to disk when executed. The challenge of adding additional sandbox/restrictions outside of the traditional uid boundaries in UNIX is challenging. The number of ways to influence a programs execution is quite sizable... On Sun, 25 Jul 1999 [EMAIL PROTECTED] wrote: jk Yes, but /if/ KTRACE is present, today's code allows you to bypass jkthe lack of read permissions on an executable. That shouldn't be jkallowed. The current behaviour could be regarded as a security jkhole actually :). sef No more so than core dumps do. Yes, but an application can protect itself from an inadvertent core dump. It can't (today) against being ktrace'd. sef I vote strongly against this change. Noted, thanks. I will summarize the result of the discussion in a followup to kern/3546. Regards, Koshy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
On Mon, Jul 26, 1999, Robert Watson wrote: Another cool attack on this mechanism is if the binary uses shared libraries: modify LD_LIBRARY_PATH so that its favorite shared library is your own version of the library, that proceeds to dump the entire application to disk when executed. The challenge of adding additional sandbox/restrictions outside of the traditional uid boundaries in UNIX is challenging. The number of ways to influence a programs execution is quite sizable... Perhaps an option when compiling the linker code to select whether to avoid or ignore LD_LIBRARY_PATH if a shared library it's looking for is in the default path. Another problem I've heard of in another OS is that if a suid root binary is dynamically linked, you could set LD_LIBRARY_PATH and make your own little libc which would, say, exec /bin/sh on something like printf. Options for both of those (or defaults) might be something to look into. Or is that second one fixed in FreeBSD? -- |Chris Costello [EMAIL PROTECTED] |[Unix] is not necessarily evil, like OS/2. - Peter Norton `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
c heard of in another OS is that if a suid root binary is c dynamically linked, you could set LD_LIBRARY_PATH and make your c own little libc which would, say, exec /bin/sh on something like c printf. Options for both of those (or defaults) might be c something to look into. Or is that second one fixed in FreeBSD? LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables in FreeBSD. Koshy [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FTPd authentication with PAM/MySQL
Hi all. I'm hoping this is a good place to post, if not, please correct me :). We're doing an entire system based on a MySQL database, that's currently able to handle SMTP/POP3 and the dialup system. The next stage I need to get going however is the web/FTPd system. I've seen the PAM modules/libraries/etc for MySQL and noticed that the FTPD Makefile has a Kerberos PAM option, and was wondering if anyone knows of a way to get FTPd talking to MySQL... or if it would work at all? Thanks for any responses; Steven Fletcher - [EMAIL PROTECTED] / [EMAIL PROTECTED] Shellnet - http://www.shellnet.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SURVEY: Sound cards that work under FreeBSD
Hi Warner, : The only line I had to add to my kernel config file was: : : device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 : : (This causes a message "pcm0 not found" to appear at boot time but : just ignoring it seems to be o.k. - allthough I would prefer : not to see it, at all.) device pcm0 does the trick for me. I think that will work in 3.2. -current fixes the problem with psm0 not found. Thanks for the hint! I got rid of the error message :-) What I still don't understand is the following message at boot time: pcm1: using I/O space register mapping at 0xe400 I am wondering why there is a message concerning pcm1 instead of pcm0... Dirk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SURVEY: Sound cards that work under FreeBSD
In message [EMAIL PROTECTED] Dirk GOUDERS writes: : What I still don't understand is the following message at boot time: : pcm1: using I/O space register mapping at 0xe400 : I am wondering why there is a message concerning pcm1 instead of pcm0... Quirks in config system in -stable cause it to usually attach to pcm1 when it is on the pci bus. It is nothing to worry about, just be aware that things like /dev/mixer, et al, need to point to the 1 unit rather than the 0 unit. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Sun, 25 Jul 1999, Mark Newton wrote: "Appropriate access" includes the idea that you need to own the mountpoint directory. If you have a system that's so badly run that arbitrary users own /tmp, then I'd say user mounts are the least of your problems :-) True. But the fact is, if I can mount arbitrary filesystems into a name space seen by all processes, I can really cause some trouble. Correct (unless you want your private stuff to be private, and chmod your mountpoint's parent directory accordingly). People seem to be far more trusting of root than I am ... OK, I'll grant you can protect it from J. Random User. Why do people feel so willing to believe that chmod solves the world's problems? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On 26 Jul 1999 12:59:57 +0200, Dag-Erling Smorgrav wrote: Don't. Instead, put it in a separate rfc(7) man page which you refer to in the services(5) man page. Cool! :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deny ktrace without read permissions?
jk The intent of this change is to prevent a user from seeing how an jk executable with '--x--x--x' perms works by ktrace'ing its execution. jk My question to -hackers is: is this a useful semantic? Would it break jk anything if added? nw If we make kernel auditing based upon KTRACE (which may or may not nw happen), this is not a useful change since we need to be able to 'audit' nw system calls regardless of whether or not KTRACE is used. If this kind This particular change should not affect the future auditing tool. The future audting tools may depend on KTRACE. The [execve] system call will still be logged as having been attempted; the control flow remains the same as for the current ``no execute perms'' case but with a stricter check if KTRACE'ing is on for the process. Right, but the system requires KTRACE as a pre-requisite for IDS, therefore we've changed the behavior of the system by adding IDS (which brings in KTRACE as a side-effect). What once was considered 'ok' previously is now not OK when IDS is added (exec'ing binaries that don't have the read permission on them..) nw If security is an issue, KTRACE shouldn't be in the system. Yes, but /if/ KTRACE is present, today's code allows you to bypass the lack of read permissions on an executable. That shouldn't be allowed. The current behaviour could be regarded as a security hole actually :). Naw. You have to reverse engineer the entire piece of code to figure out what it's doing. Knowing the syscalls is not giving you a whole lot of information. Part of the confusion comes from the meaning of the 'x' bit when KTRACE'ing is also permitted. Ordinarily the 'x' bit determines if a user can execute a file. But should execute permissions also imply the ability to trace the execution of the process? Because 'execution' is almost the same thing as 'trace' (you can't have one w/out the other), then yes. If so, the value of a permission mask like '--x--x--x' is weakened because although you cannot read the file, you can 'see inside' it, indirectly. Very indirectly. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Pasting data between terminals
hello Maybe this is a wrong list, so tell me about it, but I think you can help me :) I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. Under ttyp1 I run a program. Now I need to transport big count of datas from terminal ttyp2 to ttyp1. When I do: echo "blah blah" /dev/ttyp1 text "blah blah" appear in virtual terminal ttyp1, but only as a text of "message". I need ttyp1 count those datas as a "command typed by hand", not just a text displayed in this term as info. I must transport lots of data between these terminals. Have you any ideas? Cys - Krzysztof Krawczyk IRC on DALnet: #polska #polcafe #wroclaw [EMAIL PROTECTED] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "What sane person could live in this world and not be crazy?" -- Ursula K. LeGuin -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Wavelan-WavepointII
Yes, we have had good success with WaveLAN/IEEE Turbo cards using the wi driver in both ad-hoc mode and infrastructure mode with a WavepointII. NAT will work on the wi interface, SKIP will not. While we run IP routing instead of bridging, the underlying concept is bridging if you really mean that. Jim Flowers [EMAIL PROTECTED] #4 ISP on C|NET, #1 in Ohio On Mon, 26 Jul 1999, Kirk McDonald wrote: Hello, I am wondering if anyone has had success running bridging only between a wavelan IEEE802.11 in a BSD machine and a WavepointII using an IEEE802.11 card. I have had great succes using purely wavelan/BSD. Kirk McDonald To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:Hello, : :So, I've a box that I have an ipfw ruleset on. The firewall should not be :changeable during runtime, and the box runs at securelevel=3. : :In order to prevent DoS disk-fill attacks, I also have specified :IPFW_VERBOSE_LIMIT. : :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT :events and then you lose logging (ideally I'd zero nonzero rules once every :N minutes). : :Comments? : :... Joe : :--- :Joe Greco - Systems Administrator[EMAIL PROTECTED] Playing devil's advocate, someone might be using those counters for accounting purposes. That's about as worse a scenario as I can think of, and I can't imagine this sort of situation would be prevalient. I'd say that the counters should be clearable at high secure level. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TCP/IP hardening
Attached are patches which implement four new sysctl variables: * net.inet.icmp.dropredirect: if set to 1, ignore ICMP REDIRECT packets. * net.inet.icmp.logredirect: if set to 1, log all ICMP REDIRECT packets (before optionally dropping them). * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST packets. Conditional on the TCP_RESTRICT_RST kernel option, which defaults to off. * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN kernel option, which defaults to off. The logredirect code uses inet_ntoa, which is a bad idea. I'm open to suggestions for a better solution. Also, these sysctl variables should be described in a man page somewhere, but I'm not sure which one. These patches compile, but are not fully tested. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] Index: etc/defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/26 19:11:51 @@ -48,6 +48,11 @@ tcp_extensions="NO"# Set to Yes to turn on RFC1323 extensions. log_in_vain="NO" # Disallow bad connection logging (or YES). tcp_keepalive="YES"# Kill dead TCP connections (or NO). +tcp_restrict_rst="NO" # Set to YES to restrict emission of RST +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +icmp_dropredirect="NO" # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect="NO" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias entry. Index: etc/rc.network === RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/26 19:11:51 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 /dev/null fi + +if [ "X$icmp_dropredirect" = X"YES" ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 /dev/null +fi + +if [ "X$icmp_logredirect" = X"YES" ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 /dev/null +fi if [ "X$gateway_enable" = X"YES" ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,16 @@ if [ "X$tcp_keepalive" = X"YES" ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 /dev/null +fi + +if [ "X$tcp_restrict_rst" = X"YES" ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 /dev/null +fi + +if [ "X$tcp_drop_synfin" = X"YES" ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 /dev/null fi if [ "X$ipxgateway_enable" = X"YES" ]; then Index: sys/conf/options === RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/26 19:11:51 @@ -222,6 +222,8 @@ PPP_FILTER opt_ppp.h TCP_COMPAT_42 opt_compat.h TCPDEBUG +TCP_RESTRICT_RST opt_tcp_input.h +TCP_DROP_SYNFINopt_tcp_input.h IPFILTER opt_ipfilter.h IPFILTER_LOG opt_ipfilter.h SLIP_IFF_OPTS opt_slip.h Index: sys/i386/conf/LINT === RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT1999/07/26 05:47:17 1.620 +++ LINT1999/07/26 19:11:51 @@ -465,9 +465,23 @@ optionsIPDIVERT#divert sockets optionsIPFILTER#kernel ipfilter support optionsIPFILTER_LOG#ipfilter logging -#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsIPSTEALTH #support for stealth forwarding +#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsTCPDEBUG + +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not want to
Re: Pasting data between terminals
On Mon, Jul 26, 1999 at 08:01:22PM +0200, Krzysztof Krawczyk wrote: Maybe this is a wrong list, so tell me about it, but I think you can help me :) I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. Under ttyp1 I run a program. Now I need to transport big count of datas from terminal ttyp2 to ttyp1. When I do: echo "blah blah" /dev/ttyp1 text "blah blah" appear in virtual terminal ttyp1, but only as a text of "message". I need ttyp1 count those datas as a "command typed by hand", not just a text displayed in this term as info. I must transport lots of data between these terminals. Have you any ideas? 1) Try freebsd-questions in future. 2) Try expect. See http://expect.nist.gov/ . -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
new PPP printer for tcpdump
Hi, i've put a new PPP decode/print routine print-ppp.c for tcpdump into my home dir on freefall. It would be good if someone could verify/review it. hellmuth -- Hellmuth Michaelis[EMAIL PROTECTED] Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: wd0 DMA errors]
On Mon, 26 Jul 1999, Julian Elischer wrote: I'm not convinced that this is the same error.. the message is different.. *Nod* That's the other reason I wrote in about it. As soon as we get some other stuff cleared away I'm going to try building the world on those machines and see if the error resurfaces. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Etherboot 2.4 needs newer binutils
I need some wisdom on how to proceed. Since version 2 of Etherboot they are using the new data32 features of the Linux binutils. I know it works in binutils-2.9.1.0.25 which you can get from kernel.org or a mirror such as: http://kernel.stuph.org/pub/linux/devel/gcc I built it on -current after figuring the right host to pass to configure (it doesn't pick it up right without help). I installed the result as-new into /usr/local/bin and then modified the Etherboot Makefile to use it. Now I guess I have 2 questions: 1) When might this feature come into FreeBSD? Do we wait until this comes into the GNU release of binutils? 2) Do I make this a port so we can upgrade to the latest Etherboot release? Since they do a fair amount of active work I would like to track their latest stuff which currently we can't because our gas doesn't support "data32". Thanks, Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: You could start with "WinEXE". Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
Having a per-rule limit means that you actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit (assuming an attacker exploits multiple rules) rather than a limit of "IPFW_VERBOSE_LIMIT". I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Huh? I think you completely missed what I said - or maybe the opposite. Right now, if you have ten "log" rules, I can make your system log up to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - again assuming I can generate appropriate violations. This eats up a grossly variable amount of disk space, which seems contrary to the whole concept of IPFW_VERBOSE_LIMIT. If I'm getting attacked such that I'm logging data, I *want* as much information on the attack as possible. I realize this when I setup my IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, I'd like to see all of this. With a 'global' limit set to 100, I wouldn't see these kinds of hits. Also, from analyzing attacks for years, most attacks have a pattern that is *best* seen from seeing it hit a number of rules. By settin a per-rule limit, you 'generally' can determine that an attack is going to have a signature the same as the previous 'n' hits on that rule, but you want to see the rest of the attack. I don't care to see a scan of the IMAP 1000 times when right after they finish scanning it they also try to attack my POP3 port 1000 times. Rather, I'd rather see the first 100 attempts on the IMAP port, then the first 100 attempts on POP3, then the first 100 attempts on port 7, etc... You get *better* information on per-rule limits than on a global limit. No, you simply get a finer-grained ability to select. If I'm an admin, I'm going to think "Well lets see, I want to store a month of bad packets in it. If you're an admin on today's internet, you'd realize that there is *NO* way to get save a month worth of bad packets. Heck, at least once/week I can't even store a day's worth of bad packets (I assume when we say bad packets, we're talking about the If I'm an admin on today's internet (and I am), of course I realize that I'm not going to save a month worth of all bad packets, but I _can_ choose to hold onto a reasonable amount of logging information, which is what we are discussing. That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it allows you to sample the beginning of each 5 minute period, and you ought to be able to calculate the space required in a manner that allows you to guarantee that you have sufficient space. Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 10, and you reset the counter every 5 minutes, you still _ought_ to be able to determine that you require 2GB of disk space per day to keep those records. (And if you're getting 100K rejectable packets every 5 minutes, something is seriously wrong) I zero my counters every five minutes and there is a limit of 100 per five mins, and the average line length is 80 (or whatever) so therefore I need 80 * 100 * 12 * 24 * 30 or 70MB for my worst case scenario." Not. If the attack is the same, then the syslog error reporting will same something like (this is a real message, with IP addresses change to protect the guilty..): Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 Jun 29 16:43:44 ns last message repeated 3 times If you've got seperate attacks, then you've got too much stuff you're logging. Now given 200 rules, I can fill his disk in substantially less than a day. If you're logging that much information, then you're logging too much information. In any case, you've got information overload, so adding a global limit on the rules means you're losing as much (or more) information than you're logging, which is just as bad (or worse). No. You're not necessarily logging too much information. I do log a whole bunch of shouldn't-happen scenarios, because if they do happen, it means something is either horribly broken or somebody is doing something horribly wrong. I don't want an event such as an outbound source 10-net address to happen... in theory it can't because I filter at my borders and use no 10-net stuff internally. But I damn well want to know if it happens ANYWAYS. If you're worried about logging too much information, then don't reset your counters every 5 minutes. Besides, you're losing information if you're max'd out every 5 minutes anyway, so it really doesn't matter when you zero out your counters. You just argued my point for me, thank you. I _want_ to see the things that I choose to log, and by definition once I
Re: file(1) Magdir candidate: wintendo
In the last episode (Jul 26), Sheldon Hearn said: On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: You could start with "WinEXE". Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? What about multi-OS games, like Quake? How about just calling it "games" ? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
hot-swapping ata disks
Hi, I tried 'camcontrol rescan' and I found it works when I add a SCSI device while the system is on. I find it useful for adding/removing devices w/o restarting the box. (Maybe it's risky, but useful. I supposed that's the idea of the 'rescan' command in camcontrol) Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI anyway). Or maybe i'm walking on a wrong way? --iani To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
XFree 3.3.4 not on ftp.freebsd.org?
I was trying in vain today to get X 3.3.4 installed on my new system and couldn't seem to make it happen using sysinstall, even after I rebuilt it. AFAICS, there is no XFree 3.3.4 package available on ftp.freebsd.org/pub/FreeBSD, but I may have missed something. Fortunately it is on wcarchive, so I just pulled down all the bits and installed it the "hard" way, however I know I'm going to run into trouble down the road when ports start looking for the X stuff in /var/db/pkg. Any comments or suggestions welcome, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare plug/quickie tests.
I just wish that it was the other way around. I'd actually run NT if I could get it in a VMWare compartment under FreeBSD. You would do well to pass these sentiments on to vmware; they're currently counting noses in FreeBSD-land to see if it makes market sense. All the techs there appear to be sold on the idea, but it takes more than tech buy-in to get a project approved. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, Jul 26, 1999 at 05:29:20PM -0700, Doug wrote: and installed it the "hard" way, however I know I'm going to run into trouble down the road when ports start looking for the X stuff in /var/db/pkg. I seem to remember that you can get away with a simple "mkdir /var/db/pkg/xxx" to fake it. Alternatively, $ cd /usr/ports/x11/XFree86 ; make generate-plist fake-pkg should be a little more correct. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Free BSDI CD!
Hi, I am not sure whether this is known to this list or not, but here is the URL for ordering: http://www.bsdi.com/products/evalcd/ _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
Instead of zeroing it, how about raising the logging limit to (current + whatever the limit was) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:Instead of zeroing it, how about raising the logging limit to (current + :whatever the limit was) : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : [EMAIL PROTECTED] _ __ ___ | _ ) __| \ The way I see it either some piece of software is monitor the counters, in which case the sysad does not need to clear them and does not need to look at log messages, or the sysad is monitoring the stuff manually and using the log messages. In the one case the counters don't need to be cleared (and, indeed, should not be), in the other case the sysad may want to clear them due to the manual monitoring. What we are really discussing here is the use of ipfw's counters in an unsophisticated setup. The sophisticated setup is already handled. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999, Sheldon Hearn wrote: On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: You could start with "WinEXE". Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? No. How about "savegames"? The Quake 2 format in there would be nice, to distinguish between Q2 Windows version X.XX and Linux glibc, Linux libc5, etc... Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:That doesn't mean we shouldn't allow people to have an unsophisticated setup, :just because a sophisticated one is available. It would be useful to have :a per-firewall-rule counter, decrement it on each match if logging and :set, and be able to reset to something higher. : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ There may be some confusion here. I am advocating that we *allow* the zeroing of counters at secure level 3. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
On Mon, 26 Jul 1999, Rayson Ho wrote: Hi, I am not sure whether this is known to this list or not, but here is the URL for ordering: http://www.bsdi.com/products/evalcd/ But we can install from a single downloaded boot floppy, over the Internet, which is better. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
: : : :That doesn't mean we shouldn't allow people to have an unsophisticated setup, : :just because a sophisticated one is available. It would be useful to have : :a per-firewall-rule counter, decrement it on each match if logging and : :set, and be able to reset to something higher. : : : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : : There may be some confusion here. I am advocating that we *allow* the : zeroing of counters at secure level 3. : :Which is what I am advocating against. Let me put it a different way: ipfw allows you to clear counters. It is a feature that already exists. However, it does not allow you to do it if you are sitting at secure level 3. Why not? I can't think of any good reason why clearing the counters should be disallowed when sitting at a higher secure level. The counters are nothing more then statistics. Clearing statistics is not a security threat. The discussion should simply be about that. Not all this garbage about adding new features. There's a feature that does not seem to impact security, secure level disallows it, why? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
I needed a new drinks coaster... ;-) -marc Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com 1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: I seem to remember that you can get away with a simple "mkdir /var/db/pkg/xxx" to fake it. Can you think of any ports that test for the existance of XFree86 using the package system? They use USE_X_PREFIX or USE_X_LIB, both of which test for libX11, no? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
securelevel too course-grained?
On Mon, 26 Jul 1999 20:48:28 MST, Matthew Dillon wrote: Subject: Re: securelevel and ipfw zero However, it does not allow you to do it if you are sitting at secure level 3. You don't think that this discussion highlights the growing inadequacy of the securelevel mechanism's lack of granularity? I have a feeling it'll be time soon enough for us to make each of the decisions that is normally affected by securelevel dependant on the value of sysctl knobs. Presumeably one or more of them would be "write-once" knobs. :-) How much existing software tests for kern.securelevel? And could we make its value dependant on the new knobs? I can't see it being too big a problem. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
Sheldon Hearn wrote: On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: I seem to remember that you can get away with a simple "mkdir /var/db/pkg/xxx" to fake it. Can you think of any ports that test for the existance of XFree86 using the package system? They use USE_X_PREFIX or USE_X_LIB, both of which test for libX11, no? Well, in an ideal world the ports that need parts of X would only test for the parts that they need. However right after 3.2-R came out there was a flurry of -questions mail about broken pkg dependencies because sysinstall wasn't properly registering the X install. If the port depending on the existence of /var/db/pkg/X* is actually an error I'll report what I find to the -ports list. Thanks, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, 26 Jul 1999 22:41:24 MST, Doug wrote: However right after 3.2-R came out there was a flurry of -questions mail about broken pkg dependencies because sysinstall wasn't properly registering the X install. Is this a different problem from the broken compat22 installation? If the port depending on the existence of /var/db/pkg/X* is actually an error I'll report what I find to the -ports list. I'm pretty sure it constitutes "non-conformant" behaviour and I'd be happy to look at it. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Upgrading from 2.2.8 to 3.2-stable...
In message 199907260338.uaa01...@realtime.exit.com Frank Mayhar writes: : I'm just doing a make upgrade on a clean /usr/obj. It crashes when it gets : to libmytinfo. That's it. : : Any help or pointers would be greatly appreciated. Thanks. You might try to get a hold of 3.1 release, do a make upgrade to that, and then upgrade to 3.2-stable from there. As time marches forward, the make upgrade target tends to decay. I'm not saying that this isn't a bug, but might be more expedient than tracking down the actual problem. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: deny ktrace without read permissions?
In message 64855.932967...@axl.noc.iafrica.com Sheldon Hearn writes: : This doesn't look right. If I can execute a binary, I can have the : system allocate memory to me and but the binary image in it. It's my : memory. :-) Also, one can use a custom libc to get around the readonly ness, since functions in libc can access the entire memory space (at least on intel). Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: deny ktrace without read permissions?
In message 199907260548.waa10...@kithrup.com Sean Eric Fagan writes: : if you care about security, you made the damned executable suid or : sgid. Then ktrace, ptrace, truss, and core dumps do not work. Even : if it simply does setuid(getruid()). It also disables attacking the contents of the executable by LD_LIBRARY_PATH Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
file(1) Magdir candidate: wintendo
Hi folks, I've had some interesting comments from David Bushong, motivating for inclusion of his Magdir candidate on PR 12554. He makes a strong case for a bloated file(1) Magdir. The only thing we're battling with is a filename for his submission. Just because a bloated file(1) magic database is good, doesn't mean we want a zillion files in the Magdir source, though. So I propose a new file wintendo, for all gaming file formats used on the MS Windows platform. Sensible objections? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
Another cool attack on this mechanism is if the binary uses shared libraries: modify LD_LIBRARY_PATH so that its favorite shared library is your own version of the library, that proceeds to dump the entire application to disk when executed. The challenge of adding additional sandbox/restrictions outside of the traditional uid boundaries in UNIX is challenging. The number of ways to influence a programs execution is quite sizable... On Sun, 25 Jul 1999 jko...@freebsd.org wrote: jk Yes, but /if/ KTRACE is present, today's code allows you to bypass jkthe lack of read permissions on an executable. That shouldn't be jkallowed. The current behaviour could be regarded as a security jkhole actually :). sef No more so than core dumps do. Yes, but an application can protect itself from an inadvertent core dump. It can't (today) against being ktrace'd. sef I vote strongly against this change. Noted, thanks. I will summarize the result of the discussion in a followup to kern/3546. Regards, Koshy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Robert N M Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
On Mon, Jul 26, 1999, Robert Watson wrote: Another cool attack on this mechanism is if the binary uses shared libraries: modify LD_LIBRARY_PATH so that its favorite shared library is your own version of the library, that proceeds to dump the entire application to disk when executed. The challenge of adding additional sandbox/restrictions outside of the traditional uid boundaries in UNIX is challenging. The number of ways to influence a programs execution is quite sizable... Perhaps an option when compiling the linker code to select whether to avoid or ignore LD_LIBRARY_PATH if a shared library it's looking for is in the default path. Another problem I've heard of in another OS is that if a suid root binary is dynamically linked, you could set LD_LIBRARY_PATH and make your own little libc which would, say, exec /bin/sh on something like printf. Options for both of those (or defaults) might be something to look into. Or is that second one fixed in FreeBSD? -- |Chris Costello ch...@calldei.com |[Unix] is not necessarily evil, like OS/2. - Peter Norton `-- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
Sheldon Hearn sheld...@uunet.co.za writes: I plan to mention in the comments for each service in /etc/services, the latest RFC describing the service. Good idea. I also plan to mention in the manpage for services(5) the e-mail address to which requests for How do I get the RFCs should be sent. Don't. Instead, put it in a separate rfc(7) man page which you refer to in the services(5) man page. While you're at it, search all the other man pages for the string RFC and add a reference to rfc(7) to every page that lists an RFC as reference (e.g. fetch(3)). d...@des ~/yes% current -l RFC | grep '\.[0-9]' src/contrib/amd/scripts/expn.1 src/contrib/bind/doc/man/dig.1 src/contrib/bind/doc/man/dnskeygen.1 src/contrib/bind/doc/man/getnetent.3 src/contrib/bind/doc/man/hostname.7 src/contrib/bind/doc/man/mailaddr.7 src/contrib/bind/doc/man/named-xfer.8 src/contrib/bind/doc/man/named.8 src/contrib/bind/doc/man/nslookup.8 src/contrib/bind/doc/man/resolver.3 src/contrib/bind/doc/misc/FAQ.1of2 src/contrib/bind/doc/misc/FAQ.2of2 src/contrib/egcs/libio/dbz/dbz.1 src/contrib/egcs/libio/dbz/dbz.3z src/contrib/ipfilter/ipsend/ipresend.1 src/contrib/ipfilter/ipsend/ipsend.5 src/contrib/ipfilter/man/ipftest.1 src/contrib/isc-dhcp/client/dhclient.conf.5 src/contrib/isc-dhcp/client/dhclient.leases.5 src/contrib/isc-dhcp/common/dhcp-options.5 src/contrib/libpam/doc/man/pam.8 src/contrib/libpam/doc/man/pam_authenticate.3 src/contrib/libpam/doc/man/pam_chauthtok.3 src/contrib/libpam/doc/man/pam_fail_delay.3 src/contrib/libpam/doc/man/pam_open_session.3 src/contrib/libpam/doc/man/pam_setcred.3 src/contrib/libpam/doc/man/pam_start.3 src/contrib/libpam/doc/man/pam_strerror.3 src/contrib/libpam/doc/specs/rfc86.0.txt src/contrib/opie/opie.4 src/contrib/opie/opieftpd.8 src/contrib/patch/patch.1 src/contrib/perl5/Changes5.004 src/contrib/sendmail/src/sendmail.8 src/contrib/tcp_wrappers/hosts_access.5 src/contrib/tcp_wrappers/hosts_options.5 src/contrib/tcp_wrappers/tcpd.8 src/contrib/tcpdump/tcpdump.1 src/crypto/telnet/telnetd/telnetd.8 src/gnu/usr.bin/rcs/co/co.1 src/lib/libc/net/getnetent.3 src/lib/libc/net/resolver.3 src/lib/libc/rpc/rpc.3 src/lib/libc/rpc/rpc_secure.3 src/lib/libc/sys/rfork.2 src/lib/libc/xdr/xdr.3 src/lib/libfetch/fetch.3 src/lib/libmd/mdX.3 src/lib/libradius/libradius.3 src/lib/libradius/radius.conf.5 src/lib/libz/zlib.3 src/libexec/bootpd/bootpd.8 src/libexec/bootpd/bootptab.5 src/libexec/bootpd/tools/bootpef/bootpef.8 src/libexec/bootpd/tools/bootptest/bootptest.8 src/libexec/fingerd/fingerd.8 src/libexec/ftpd/ftpd.8 src/libexec/telnetd/telnetd.8 src/libexec/tftpd/tftpd.8 src/sbin/i386/cxconfig/cxconfig.8 src/sbin/md5/md5.1 src/sbin/mount_nfs/mount_nfs.8 src/sbin/mountd/exports.5 src/sbin/mountd/mountd.8 src/sbin/nfsd/nfsd.8 src/sbin/routed/routed.8 src/sbin/routed/rtquery/rtquery.8 src/sbin/spppcontrol/spppcontrol.8 src/share/examples/mdoc/example.1 src/share/examples/mdoc/example.3 src/share/man/man4/ifmib.4 src/share/man/man4/ip.4 src/share/man/man4/sppp.4 src/share/man/man4/tcp.4 src/share/man/man4/ttcp.4 src/share/man/man5/rc.conf.5 src/share/man/man7/mailaddr.7 src/share/man/man9/MD5.9 src/usr.bin/fetch/fetch.1 src/usr.bin/finger/finger.1 src/usr.bin/ftp/ftp.1 src/usr.bin/showmount/showmount.8 src/usr.bin/whois/whois.1 src/usr.sbin/arp/arp.4 src/usr.sbin/atm/atmarpd/atmarpd.8 src/usr.sbin/atm/scspd/scspd.8 src/usr.sbin/inetd/inetd.8 src/usr.sbin/mrouted/mrouted.8 src/usr.sbin/ppp/ppp.8 src/usr.sbin/pppd/pppd.8 src/usr.sbin/rarpd/rarpd.8 src/usr.sbin/rndcontrol/random.4 src/usr.sbin/xntpd/doc/xntpd.8 src/usr.sbin/xntpd/doc/xntpdc.8 DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
c heard of in another OS is that if a suid root binary is c dynamically linked, you could set LD_LIBRARY_PATH and make your c own little libc which would, say, exec /bin/sh on something like c printf. Options for both of those (or defaults) might be c something to look into. Or is that second one fixed in FreeBSD? LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables in FreeBSD. Koshy jko...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
FTPd authentication with PAM/MySQL
Hi all. I'm hoping this is a good place to post, if not, please correct me :). We're doing an entire system based on a MySQL database, that's currently able to handle SMTP/POP3 and the dialup system. The next stage I need to get going however is the web/FTPd system. I've seen the PAM modules/libraries/etc for MySQL and noticed that the FTPD Makefile has a Kerberos PAM option, and was wondering if anyone knows of a way to get FTPd talking to MySQL... or if it would work at all? Thanks for any responses; Steven Fletcher - ste...@shellnet.co.uk / f...@flec.co.uk Shellnet - http://www.shellnet.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
On Mon, Jul 26, 1999 at 04:16:28AM -0700, jko...@freebsd.org wrote: LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables in FreeBSD. But the point being made is that they are not ignored for executables which have no read access. And from there, read access can be gained, because at that point, you have code running in the process's address space. -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SURVEY: Sound cards that work under FreeBSD
Hi Warner, : The only line I had to add to my kernel config file was: : : device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 : : (This causes a message pcm0 not found to appear at boot time but : just ignoring it seems to be o.k. - allthough I would prefer : not to see it, at all.) device pcm0 does the trick for me. I think that will work in 3.2. -current fixes the problem with psm0 not found. Thanks for the hint! I got rid of the error message :-) What I still don't understand is the following message at boot time: pcm1: using I/O space register mapping at 0xe400 I am wondering why there is a message concerning pcm1 instead of pcm0... Dirk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Squid - a bug in src/sys/kern/uipc_socket.c
PRUS_MORETOCOME is indeed too complex to solve the microcosmic problem of writes between 100 and 208 bytes; however, it solves the more general problem of the Nagle/MTU interaction even when the MTU is larger than a cluster (e.g. loopback, ATM, FDDI, etc). Try the atomic patch (and remove PRUS_MORETOCOME) with writes of 2049-2256 bytes on the loopback interface. Same with LOCAL-domain sockets (with the uipc_usrreq.c patch I sent you). Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SURVEY: Sound cards that work under FreeBSD
In message 199907261246.oaa00...@musashi.et.bocholt.fh-ge.de Dirk GOUDERS writes: : What I still don't understand is the following message at boot time: : pcm1: using I/O space register mapping at 0xe400 : I am wondering why there is a message concerning pcm1 instead of pcm0... Quirks in config system in -stable cause it to usually attach to pcm1 when it is on the pci bus. It is nothing to worry about, just be aware that things like /dev/mixer, et al, need to point to the 1 unit rather than the 0 unit. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
On Sat, 24 Jul 1999, Oliver Fromme wrote: Ronald G. Minnich wrote in list.freebsd-hackers: Or, let's say I don't have appropriate access to /tmp. Pick some other place. I mount my file system there for my files. Now everyone who wants can look for these user mounts and walk them at will. My private stuff is quite public. You own it, so you can set the permission appropriately, so nobody else can access it if you don't want that. not really. You're assuming that you, as a remote user, trust root. That's not a good assumption in a distributed computing environment. Someone you don't know can become root, root can become anyone, then become you, then the permissions are a moot point. You're also assuming that the owner of the system is willing to let you own a file in the local file system. They may let you be willing to use their cycles, in trade for some of your cycles, but they may be a lot less willing to let you see their filesystems. These are both faulty assumptions in distributed computing environments. People have killed distributed computing in some organizations for these reasons. ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
On Sun, 25 Jul 1999, Mark Newton wrote: Appropriate access includes the idea that you need to own the mountpoint directory. If you have a system that's so badly run that arbitrary users own /tmp, then I'd say user mounts are the least of your problems :-) True. But the fact is, if I can mount arbitrary filesystems into a name space seen by all processes, I can really cause some trouble. Correct (unless you want your private stuff to be private, and chmod your mountpoint's parent directory accordingly). People seem to be far more trusting of root than I am ... OK, I'll grant you can protect it from J. Random User. Why do people feel so willing to believe that chmod solves the world's problems? ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
On Sun, 25 Jul 1999, Brian F. Feldman wrote: On Sun, 25 Jul 1999, Mark Newton wrote: Ronald G. Minnich wrote: But thanks for the note. I just now realized that if I add a private name space to v9fs (which is easy), and then turn on user mounts, user processes can have private name spaces on freebsd! I can't wait to see the security problems that causes when setuid executables assume that they only need to be worrying about one filesystem namespace. :-) There shouldn't be any problems if mount enabled the flags for nosuid/nodev etc. if suser(p) != 0. Actually, i'd expect far fewer problems for the private mounts than for user mounts which modify the name space for all processes ... ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
On 26 Jul 1999 12:59:57 +0200, Dag-Erling Smorgrav wrote: Don't. Instead, put it in a separate rfc(7) man page which you refer to in the services(5) man page. Cool! :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: InterMezzo: Project for kernel/FS hackers
Date: Thu, 22 Jul 1999 21:19:46 +0100 From: Nik Clayton n...@nothing-going-on.demon.co.uk Has anyone had the chance to look at InterMezzo, website at http://www.inter-mezzo.org/ Coda (which already has a FreeBSD port) also does this, as well as a few other things. However, Coda is much more heavyweight than InterMezzo, and therefore easier to understand -- in particular, Coda seems to have (according to one of the Coda developers) a marked preference for exporting whole filesystems, InterMezzo allows you to export individual directory trees. Anyway, if any aspiring kernel hackers are looking for a project, that might be a fun one. The only implementation at the moment is for Linux. FWIW, I believe BayLISA is planning/hoping to have a speaker at one of our monthly meetings soon. (That's SF Bay area: http://www.baylisa.org/. Anyone in the area at the time is welcome to attend -- no charge. Meetings are on the 3rd Thursday of the month, starting at 7:30 PM. They've been held in Santa Clara recently, though that's in a state of flux at the moment.)
Re: deny ktrace without read permissions?
jk The intent of this change is to prevent a user from seeing how an jk executable with '--x--x--x' perms works by ktrace'ing its execution. jk My question to -hackers is: is this a useful semantic? Would it break jk anything if added? nw If we make kernel auditing based upon KTRACE (which may or may not nw happen), this is not a useful change since we need to be able to 'audit' nw system calls regardless of whether or not KTRACE is used. If this kind This particular change should not affect the future auditing tool. The future audting tools may depend on KTRACE. The [execve] system call will still be logged as having been attempted; the control flow remains the same as for the current ``no execute perms'' case but with a stricter check if KTRACE'ing is on for the process. Right, but the system requires KTRACE as a pre-requisite for IDS, therefore we've changed the behavior of the system by adding IDS (which brings in KTRACE as a side-effect). What once was considered 'ok' previously is now not OK when IDS is added (exec'ing binaries that don't have the read permission on them..) nw If security is an issue, KTRACE shouldn't be in the system. Yes, but /if/ KTRACE is present, today's code allows you to bypass the lack of read permissions on an executable. That shouldn't be allowed. The current behaviour could be regarded as a security hole actually :). Naw. You have to reverse engineer the entire piece of code to figure out what it's doing. Knowing the syscalls is not giving you a whole lot of information. Part of the confusion comes from the meaning of the 'x' bit when KTRACE'ing is also permitted. Ordinarily the 'x' bit determines if a user can execute a file. But should execute permissions also imply the ability to trace the execution of the process? Because 'execution' is almost the same thing as 'trace' (you can't have one w/out the other), then yes. If so, the value of a permission mask like '--x--x--x' is weakened because although you cannot read the file, you can 'see inside' it, indirectly. Very indirectly. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: deny ktrace without read permissions?
The PR proposes (and the patch given earlier implements) tighter security on the premise that security in the presence of KTRACE should be at least as tight as without KTRACE. It achieves this by requiring read permissions on an executable before it can be KTRACE'd. As other have pointed out, if you're good enough to reverse engineer a program from just it's syscall, you're probably good enough to stick in a new shared library that allows you to 'reverse engineer' w/out requiring KTRACE. Again, security through obscurity is never a good solution, and this is just that wrapped in different clothes. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables in FreeBSD. But the point being made is that they are not ignored for executables which have no read access. And from there, read access can be gained, because at that point, you have code running in the process's address space. That's right. In other words, there really is no way of protecting executable files from being read if someone is motivated enough. And, in an open-source OS like FreeBSD, it's not a viable solution in any case Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
On Mon, Jul 26, 1999, Nate Williams wrote: LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables in FreeBSD. But the point being made is that they are not ignored for executables which have no read access. And from there, read access can be gained, because at that point, you have code running in the process's address space. That's right. In other words, there really is no way of protecting executable files from being read if someone is motivated enough. And, in an open-source OS like FreeBSD, it's not a viable solution in any case The only option, as I've mentined previously in this thread, that I can think of, would be to have an option when building various linker code to disable searching in $LD_LIBRARY_PATH if the library being looked for is in the standard library paths. -- |Chris Costello ch...@calldei.com |Is reading in the bathroom considered Multi-Tasking? ` To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables in FreeBSD. But the point being made is that they are not ignored for executables which have no read access. And from there, read access can be gained, because at that point, you have code running in the process's address space. That's right. In other words, there really is no way of protecting executable files from being read if someone is motivated enough. And, in an open-source OS like FreeBSD, it's not a viable solution in any case The only option, as I've mentined previously in this thread, that I can think of, would be to have an option when building various linker code to disable searching in $LD_LIBRARY_PATH if the library being looked for is in the standard library paths. Except that's only *one* of the ways. There's still ptrace and /proc, so you'd have to hunt them down as well. However, assuming you've hunted them all down, you may be removing useful functionality from the system that is currently used, so it's not worth it. SEF's solution of doing a 'setuid(getuid());' is a good solution that solves the problems listed, and doesn't require any modifications to the system. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
:On Mon, Jul 26, 1999, Nate Williams wrote: : LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables : in FreeBSD. : : But the point being made is that they are not ignored for executables : which have no read access. And from there, read access can be gained, : because at that point, you have code running in the process's address : space. : : That's right. In other words, there really is no way of protecting : executable files from being read if someone is motivated enough. : : And, in an open-source OS like FreeBSD, it's not a viable solution in : any case : : The only option, as I've mentined previously in this thread, :that I can think of, would be to have an option when building :various linker code to disable searching in $LD_LIBRARY_PATH if :the library being looked for is in the standard library paths. : :-- :|Chris Costello ch...@calldei.com LD_LIBRARY_PATH was a huge security hole when it was first introduced and you know what? It STILL IS! We are opening up a can of worms here. It's one of those things where we either have to make the decision to try to protect the binary that the owner decided to make execute-only, or to give up. * LD_LIBRARY_PATH? * core dumps for execute-only binaries? * ktrace for execute-only binaries? If I were to put my foot down I would say off with their heads! i.e. disallow all three if the non-root-run binary is execute-only. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Pasting data between terminals
hello Maybe this is a wrong list, so tell me about it, but I think you can help me :) I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. Under ttyp1 I run a program. Now I need to transport big count of datas from terminal ttyp2 to ttyp1. When I do: echo blah blah /dev/ttyp1 text blah blah appear in virtual terminal ttyp1, but only as a text of message. I need ttyp1 count those datas as a command typed by hand, not just a text displayed in this term as info. I must transport lots of data between these terminals. Have you any ideas? Cys - Krzysztof Krawczyk IRC on DALnet: #polska #polcafe #wroclaw c...@for.lames.access.is.denied.cx -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= What sane person could live in this world and not be crazy? -- Ursula K. LeGuin -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Wavelan-WavepointII
Yes, we have had good success with WaveLAN/IEEE Turbo cards using the wi driver in both ad-hoc mode and infrastructure mode with a WavepointII. NAT will work on the wi interface, SKIP will not. While we run IP routing instead of bridging, the underlying concept is bridging if you really mean that. Jim Flowers jflow...@ezo.net #4 ISP on C|NET, #1 in Ohio On Mon, 26 Jul 1999, Kirk McDonald wrote: Hello, I am wondering if anyone has had success running bridging only between a wavelan IEEE802.11 in a BSD machine and a WavepointII using an IEEE802.11 card. I have had great succes using purely wavelan/BSD. Kirk McDonald To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: wd0 DMA errors]
I'm not convinced that this is the same error.. the message is different.. On Sun, 25 Jul 1999, Doug wrote: Sheldon Hearn wrote: On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: No answer on -current, any help appreciated. We're probably all sitting here thinking I'm sure this was asked and answered recently. He can read his CURRENT mail like the rest of us. I have indeed read my -current mail. Several bugs in the PCI and DMA code have been mentioned in the past week, but frankly I don't have enough expertise in either to know for sure that the bugs mentioned would produce the error messages I saw. A simple, yes, those were the bugs fixed recently is all that was needed. Thank you, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
securelevel and ipfw zero
Hello, So, I've a box that I have an ipfw ruleset on. The firewall should not be changeable during runtime, and the box runs at securelevel=3. In order to prevent DoS disk-fill attacks, I also have specified IPFW_VERBOSE_LIMIT. Now, the problem is, in securelevel 3, you cannot zero a rule's counter, so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT events and then you lose logging (ideally I'd zero nonzero rules once every N minutes). Comments? ... Joe --- Joe Greco - Systems Administrator jgr...@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
:Hello, : :So, I've a box that I have an ipfw ruleset on. The firewall should not be :changeable during runtime, and the box runs at securelevel=3. : :In order to prevent DoS disk-fill attacks, I also have specified :IPFW_VERBOSE_LIMIT. : :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT :events and then you lose logging (ideally I'd zero nonzero rules once every :N minutes). : :Comments? : :... Joe : :--- :Joe Greco - Systems Administratorjgr...@ns.sol.net Playing devil's advocate, someone might be using those counters for accounting purposes. That's about as worse a scenario as I can think of, and I can't imagine this sort of situation would be prevalient. I'd say that the counters should be clearable at high secure level. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
:Hello, : :So, I've a box that I have an ipfw ruleset on. The firewall should not be :changeable during runtime, and the box runs at securelevel=3. : :In order to prevent DoS disk-fill attacks, I also have specified :IPFW_VERBOSE_LIMIT. : :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT :events and then you lose logging (ideally I'd zero nonzero rules once every :N minutes). : :Comments? Playing devil's advocate, someone might be using those counters for accounting purposes. That's about as worse a scenario as I can think of, and I can't imagine this sort of situation would be prevalient. I'd say that the counters should be clearable at high secure level. Then there should be a separate counter for logging purposes...? I do not care if the accounting counters do not clear (ever), since things like MRTG are designed to deal with that situation. However, it seems bad that you would not be able to clear your counter for logging purposes, just in case you actually _did_ mean that you want bad packets to be logged. I will also note that it would be acceptable, to me at least, to maintain a global (rather than per-rule) limit for the verbose limit. In general, I would think that someone who uses the limit facility is trying to avoid a DoS style disk-space attack. Having a per-rule limit means that you actually have a IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log limit (assuming an attacker exploits multiple rules) rather than a limit of IPFW_VERBOSE_LIMIT. It also makes it more difficult to code in a bunch of log rules, since your periodic zero script has to know the number of each one, and if you just do an ipfw zero rule1 rule2 rule3 then you get a bunch of /kernel: ipfw: Entry rule1 cleared. /kernel: ipfw: Entry rule2 cleared. /kernel: ipfw: Entry rule3 cleared. each time you do this. I would rather see something like /kernel: ipfw: logging limit reached, suspending. # /sbin/ipfw zerolog /kernel: ipfw: logging limit reset, resuming. I can deal with it (in code) if there is a per-rule log counter as well, but what you are telling me makes it sound more attractive to have a global logging counter. Comments? ... Joe --- Joe Greco - Systems Administrator jgr...@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
DPT SmartRAID V (i2o) Status
Hi Y'll Several of you ask, so here is a generic answer; I am actively working on i2o subsystem for FreeBSD. The reference card for this work is the DPT 5th Generation controllers. Status: Much of the work, particularly IRT DPT controllers is complete. All the mechanics and kernel modifications to allow recognition of i2o card and in particular DPT cards is in place. I am able, routinely to: * Detect the cards * Negotiate setup and configuration * Initialize the IOP * Build a list of all devices known * Query device attributes and capabilities * Notify the kernel of known devices * Accept block I/O requests, send to the IOP, return results. * Accept character (raw) device I/O requests, translate to Block I/O requests, process and reply. * Still to be done: * Complete debugging disklabel code. * Add fdisk slice code * Mature and stabilize error handling * Complete port of dptutil (RAID management. Most Helpful Help: Fdisk Slice, disklabel, and devfs code completion. Personal Note; I am so swamped with work that I have little time, if any, for participation in mailing list activities. This is NOT to say that I am not active in FreeBSD, or the i2o project. If you need me, or like to chat, drop me a line! -- Sincerely Yours, Simon Shapiro Research FellowMindSpring Enterprises shapi...@mindspring.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
:So, I've a box that I have an ipfw ruleset on. The firewall should not be :changeable during runtime, and the box runs at securelevel=3. : :In order to prevent DoS disk-fill attacks, I also have specified :IPFW_VERBOSE_LIMIT. FWIW, as you pointed out below, this was put in specifically to avoid a DoS attack. :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT :events and then you lose logging (ideally I'd zero nonzero rules once every :N minutes). : :Comments? Playing devil's advocate, someone might be using those counters for accounting purposes. That's about as worse a scenario as I can think of, and I can't imagine this sort of situation would be prevalient. I'd say that the counters should be clearable at high secure level. Then there should be a separate counter for logging purposes...? I do not care if the accounting counters do not clear (ever), since things like MRTG are designed to deal with that situation. MRTG? However, it seems bad that you would not be able to clear your counter for logging purposes, just in case you actually _did_ mean that you want bad packets to be logged. *grin* I will also note that it would be acceptable, to me at least, to maintain a global (rather than per-rule) limit for the verbose limit. In general, I would think that someone who uses the limit facility is trying to avoid a DoS style disk-space attack. Agreed, see above. Having a per-rule limit means that you actually have a IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log limit (assuming an attacker exploits multiple rules) rather than a limit of IPFW_VERBOSE_LIMIT. I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Case in point, I may at one time want to 'log' all connections to a particular port, and then later ignore (no longer log) all the connections to that port *except* to a particular host. Or, the reverse may be true. In these cases, I don't want to have to recompile my kernel to allow 'more logging' of the information. I think a 'per-rule' limit works best, instead of a global limit. This also works well in the case of rootkit attempt breakins, since they tend to hit one rule multiple times, and then another multiple times, etc... With a 'global' limit, I may end up 'limiting out' on the first rule, and then miss all the rules hit later on with the attack. It also makes it more difficult to code in a bunch of log rules, since your periodic zero script has to know the number of each one, and if you just do an ipfw zero rule1 rule2 rule3 then you get a bunch of /kernel: ipfw: Entry rule1 cleared. /kernel: ipfw: Entry rule2 cleared. /kernel: ipfw: Entry rule3 cleared. each time you do this. Or, you do like I do, and have a cronjob 'zero' out the entire log ruleset everynight right after it sends the results to me to analyze. However, at times (during breakins I happen to catch, or during ruleset debugging sessions) I still want to have control over individual rules. I would rather see something like /kernel: ipfw: logging limit reached, suspending. # /sbin/ipfw zerolog /kernel: ipfw: logging limit reset, resuming. This is essentially what I do. But, you can do 'ipfw zero' which accomplishes the same thing. However, this is really a side-issue. The last thing I'll say is that I think a 'global' counter is a bad idea, and this is from using IPFW for years in a real/deployed FreeBSD firewall situation. It would cause me more trouble than it's worth, and provide 'less' flexibility than currently exists (which I use). The real issue from your first email is '*should* ipfw rules be 'zero-able' at securelevel 3'. I'm of two minds. The paranoid administrator can't think of any bad things that could occur, but I can imagine something bad happening if someone were allowed to do this, although it's not completely concrete. I don't have the brain-cells to dedicate to thinking about the full implications of a 'bad-guy' zeroing out my rules. On the other, the firewall administrator who actually has to use this darn system is less worried about breakins and such, thinking that if someone compromised my system at high securelevels, they could do more damage to my system in other ways than by zeroing out my firewall numbers. But, then again if we're in securelevel 3, we shouldn't let *anyone* do anything to the system, since we're paranoid about anything negative happening to my system. In other words, I'm not sure what is the 'right' thing to do here. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
:So, I've a box that I have an ipfw ruleset on. The firewall should not be :changeable during runtime, and the box runs at securelevel=3. : :In order to prevent DoS disk-fill attacks, I also have specified :IPFW_VERBOSE_LIMIT. FWIW, as you pointed out below, this was put in specifically to avoid a DoS attack. :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT :events and then you lose logging (ideally I'd zero nonzero rules once every :N minutes). : :Comments? Playing devil's advocate, someone might be using those counters for accounting purposes. That's about as worse a scenario as I can think of, and I can't imagine this sort of situation would be prevalient. I'd say that the counters should be clearable at high secure level. Then there should be a separate counter for logging purposes...? I do not care if the accounting counters do not clear (ever), since things like MRTG are designed to deal with that situation. MRTG? multi-router traffic grapher. Put a SNMP interface between that and ipfw and wh instant traffic graphing. However, it seems bad that you would not be able to clear your counter for logging purposes, just in case you actually _did_ mean that you want bad packets to be logged. *grin* I will also note that it would be acceptable, to me at least, to maintain a global (rather than per-rule) limit for the verbose limit. In general, I would think that someone who uses the limit facility is trying to avoid a DoS style disk-space attack. Agreed, see above. Having a per-rule limit means that you actually have a IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log limit (assuming an attacker exploits multiple rules) rather than a limit of IPFW_VERBOSE_LIMIT. I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Huh? I think you completely missed what I said - or maybe the opposite. Right now, if you have ten log rules, I can make your system log up to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - again assuming I can generate appropriate violations. This eats up a grossly variable amount of disk space, which seems contrary to the whole concept of IPFW_VERBOSE_LIMIT. If I'm an admin, I'm going to think Well lets see, I want to store a month of bad packets in it. I zero my counters every five minutes and there is a limit of 100 per five mins, and the average line length is 80 (or whatever) so therefore I need 80 * 100 * 12 * 24 * 30 or 70MB for my worst case scenario. Now given 200 rules, I can fill his disk in substantially less than a day. I don't know what you mean by make the rules 'more verbose' but what I am advocating is not any change in what currently exists... I am talking about limiting the number of entries possible in a manner that would seem to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. Case in point, I may at one time want to 'log' all connections to a particular port, and then later ignore (no longer log) all the connections to that port *except* to a particular host. Or, the reverse may be true. In these cases, I don't want to have to recompile my kernel to allow 'more logging' of the information. Huh? Why would you have to recompile your kernel? Assuming securelevel 3, which is required regardless... you just delete the less restrictive rule and replace it with a more restrictive rule. What I am discussing does not affect this at all. If you are afraid of hitting the VERBOSE_LIMIT, that is why you would have an additional command such as ipfw zerolog. I think a 'per-rule' limit works best, instead of a global limit. This also works well in the case of rootkit attempt breakins, since they tend to hit one rule multiple times, and then another multiple times, etc... With a 'global' limit, I may end up 'limiting out' on the first rule, and then miss all the rules hit later on with the attack. Yes, you might. But you might miss them anyways, and I can run you out of disk space quicker. It also makes it more difficult to code in a bunch of log rules, since your periodic zero script has to know the number of each one, and if you just do an ipfw zero rule1 rule2 rule3 then you get a bunch of /kernel: ipfw: Entry rule1 cleared. /kernel: ipfw: Entry rule2 cleared. /kernel: ipfw: Entry rule3 cleared. each time you do this. Or, you do like I do, and have a cronjob 'zero' out the entire log ruleset everynight right after it sends the results to me to analyze. Interferes with your accounting counters. You need to be able to do them individually to avoid that.
Re: file(1) Magdir candidate: wintendo
So I propose a new file wintendo, for all gaming file formats used on the MS Windows platform. Wintendo is a bad name for anything official. Try to find MS's official name for the format(s). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
TCP/IP hardening
Attached are patches which implement four new sysctl variables: * net.inet.icmp.dropredirect: if set to 1, ignore ICMP REDIRECT packets. * net.inet.icmp.logredirect: if set to 1, log all ICMP REDIRECT packets (before optionally dropping them). * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST packets. Conditional on the TCP_RESTRICT_RST kernel option, which defaults to off. * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN kernel option, which defaults to off. The logredirect code uses inet_ntoa, which is a bad idea. I'm open to suggestions for a better solution. Also, these sysctl variables should be described in a man page somewhere, but I'm not sure which one. These patches compile, but are not fully tested. DES -- Dag-Erling Smorgrav - d...@yes.no Index: etc/defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/26 19:11:51 @@ -48,6 +48,11 @@ tcp_extensions=NO# Set to Yes to turn on RFC1323 extensions. log_in_vain=NO # Disallow bad connection logging (or YES). tcp_keepalive=YES# Kill dead TCP connections (or NO). +tcp_restrict_rst=NO # Set to YES to restrict emission of RST +tcp_drop_synfin=NO # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +icmp_dropredirect=NO # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect=NO # Set to YES to log ICMP REDIRECT packets network_interfaces=auto # List of network interfaces (or auto). ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. #ifconfig_lo0_alias0=inet 127.0.0.254 netmask 0x # Sample alias entry. Index: etc/rc.network === RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/26 19:11:51 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 /dev/null fi + +if [ X$icmp_dropredirect = XYES ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 /dev/null +fi + +if [ X$icmp_logredirect = XYES ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 /dev/null +fi if [ X$gateway_enable = XYES ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,16 @@ if [ X$tcp_keepalive = XYES ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 /dev/null +fi + +if [ X$tcp_restrict_rst = XYES ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 /dev/null +fi + +if [ X$tcp_drop_synfin = XYES ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 /dev/null fi if [ X$ipxgateway_enable = XYES ]; then Index: sys/conf/options === RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/26 19:11:51 @@ -222,6 +222,8 @@ PPP_FILTER opt_ppp.h TCP_COMPAT_42 opt_compat.h TCPDEBUG +TCP_RESTRICT_RST opt_tcp_input.h +TCP_DROP_SYNFINopt_tcp_input.h IPFILTER opt_ipfilter.h IPFILTER_LOG opt_ipfilter.h SLIP_IFF_OPTS opt_slip.h Index: sys/i386/conf/LINT === RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT1999/07/26 05:47:17 1.620 +++ LINT1999/07/26 19:11:51 @@ -465,9 +465,23 @@ optionsIPDIVERT#divert sockets optionsIPFILTER#kernel ipfilter support optionsIPFILTER_LOG#ipfilter logging -#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsIPSTEALTH #support for stealth forwarding +#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsTCPDEBUG + +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not want to be easily portscannable. +# +# TCP_DROP_SYNFIN adds
Re: securelevel and ipfw zero
Having a per-rule limit means that you actually have a IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log limit (assuming an attacker exploits multiple rules) rather than a limit of IPFW_VERBOSE_LIMIT. I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Huh? I think you completely missed what I said - or maybe the opposite. Right now, if you have ten log rules, I can make your system log up to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - again assuming I can generate appropriate violations. This eats up a grossly variable amount of disk space, which seems contrary to the whole concept of IPFW_VERBOSE_LIMIT. If I'm getting attacked such that I'm logging data, I *want* as much information on the attack as possible. I realize this when I setup my IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, I'd like to see all of this. With a 'global' limit set to 100, I wouldn't see these kinds of hits. Also, from analyzing attacks for years, most attacks have a pattern that is *best* seen from seeing it hit a number of rules. By settin a per-rule limit, you 'generally' can determine that an attack is going to have a signature the same as the previous 'n' hits on that rule, but you want to see the rest of the attack. I don't care to see a scan of the IMAP 1000 times when right after they finish scanning it they also try to attack my POP3 port 1000 times. Rather, I'd rather see the first 100 attempts on the IMAP port, then the first 100 attempts on POP3, then the first 100 attempts on port 7, etc... You get *better* information on per-rule limits than on a global limit. If I'm an admin, I'm going to think Well lets see, I want to store a month of bad packets in it. If you're an admin on today's internet, you'd realize that there is *NO* way to get save a month worth of bad packets. Heck, at least once/week I can't even store a day's worth of bad packets (I assume when we say bad packets, we're talking about the I zero my counters every five minutes and there is a limit of 100 per five mins, and the average line length is 80 (or whatever) so therefore I need 80 * 100 * 12 * 24 * 30 or 70MB for my worst case scenario. Not. If the attack is the same, then the syslog error reporting will same something like (this is a real message, with IP addresses change to protect the guilty..): Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 Jun 29 16:43:44 ns last message repeated 3 times If you've got seperate attacks, then you've got too much stuff you're logging. Now given 200 rules, I can fill his disk in substantially less than a day. If you're logging that much information, then you're logging too much information. In any case, you've got information overload, so adding a global limit on the rules means you're losing as much (or more) information than you're logging, which is just as bad (or worse). If you're worried about logging too much information, then don't reset your counters every 5 minutes. Besides, you're losing information if you're max'd out every 5 minutes anyway, so it really doesn't matter when you zero out your counters. I don't know what you mean by make the rules 'more verbose' but what I am advocating is not any change in what currently exists... I am talking about limiting the number of entries possible in a manner that would seem to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most attacks don't hit the entire system on every rule in order to do a DoS attack. Even so, each rule with eventually 'limit-out' and the system will no longer log packets. This is a 'bad thing' from a security standpoint, since at that point we are losing information. The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still allowing *MAXIMUM* data collection when a DoS attack is not happening. It's not there to make your logfiles small. If you want small logfiles, turn of IPFW logging altogether. (I'm actually serious here.) Case in point, I may at one time want to 'log' all connections to a particular port, and then later ignore (no longer log) all the connections to that port *except* to a particular host. Or, the reverse may be true. In these cases, I don't want to have to recompile my kernel to allow 'more logging' of the information. Huh? Why would you have to recompile your kernel? Assuming securelevel 3, which is required regardless... you just delete the less restrictive rule and replace it with a more restrictive rule. I want *both* rules, and I want *full* information disclosure since I want to
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: Wintendo is a bad name for anything official. Try to find MS's official name for the format(s). You're hoping for a standard name for file formats of games used on Microsoft platformat? There are two words in that question that one doesn't usually fine together in a sentence that doesn't contain the word bastardize. :-) I'll try... Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pasting data between terminals
On Mon, Jul 26, 1999 at 08:01:22PM +0200, Krzysztof Krawczyk wrote: Maybe this is a wrong list, so tell me about it, but I think you can help me :) I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. Under ttyp1 I run a program. Now I need to transport big count of datas from terminal ttyp2 to ttyp1. When I do: echo blah blah /dev/ttyp1 text blah blah appear in virtual terminal ttyp1, but only as a text of message. I need ttyp1 count those datas as a command typed by hand, not just a text displayed in this term as info. I must transport lots of data between these terminals. Have you any ideas? 1) Try freebsd-questions in future. 2) Try expect. See http://expect.nist.gov/ . -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:46:31 +0200, Sheldon Hearn wrote: You're hoping for a standard name for file formats of games used on Microsoft platformat? Duh, I'm being obtuse. Your question indicates that I've phrased my proposal in such a way as to suggest that this is for formats of Microsoft games. That's not what I meant. I meant games used on the Microsoft platforms. However, it occurs to me that this is stupid, since the same game may be available on multiple PC platforms, all using the same file format. So... how about pcgames as the name of the file? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
new PPP printer for tcpdump
Hi, i've put a new PPP decode/print routine print-ppp.c for tcpdump into my home dir on freefall. It would be good if someone could verify/review it. hellmuth -- Hellmuth Michaelish...@kts.org Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: wd0 DMA errors]
On Mon, 26 Jul 1999, Julian Elischer wrote: I'm not convinced that this is the same error.. the message is different.. *Nod* That's the other reason I wrote in about it. As soon as we get some other stuff cleared away I'm going to try building the world on those machines and see if the error resurfaces. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Etherboot 2.4 needs newer binutils
I need some wisdom on how to proceed. Since version 2 of Etherboot they are using the new data32 features of the Linux binutils. I know it works in binutils-2.9.1.0.25 which you can get from kernel.org or a mirror such as: http://kernel.stuph.org/pub/linux/devel/gcc I built it on -current after figuring the right host to pass to configure (it doesn't pick it up right without help). I installed the result as-new into /usr/local/bin and then modified the Etherboot Makefile to use it. Now I guess I have 2 questions: 1) When might this feature come into FreeBSD? Do we wait until this comes into the GNU release of binutils? 2) Do I make this a port so we can upgrade to the latest Etherboot release? Since they do a fair amount of active work I would like to track their latest stuff which currently we can't because our gas doesn't support data32. Thanks, Doug A. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: Wintendo is a bad name for anything official. Try to find MS's official name for the format(s). You're hoping for a standard name for file formats of games used on Microsoft platformat? There are two words in that question that one doesn't usually fine together in a sentence that doesn't contain the word bastardize. :-) You could start with WinEXE. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: You could start with WinEXE. Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
Having a per-rule limit means that you actually have a IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log limit (assuming an attacker exploits multiple rules) rather than a limit of IPFW_VERBOSE_LIMIT. I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Huh? I think you completely missed what I said - or maybe the opposite. Right now, if you have ten log rules, I can make your system log up to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - again assuming I can generate appropriate violations. This eats up a grossly variable amount of disk space, which seems contrary to the whole concept of IPFW_VERBOSE_LIMIT. If I'm getting attacked such that I'm logging data, I *want* as much information on the attack as possible. I realize this when I setup my IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, I'd like to see all of this. With a 'global' limit set to 100, I wouldn't see these kinds of hits. Also, from analyzing attacks for years, most attacks have a pattern that is *best* seen from seeing it hit a number of rules. By settin a per-rule limit, you 'generally' can determine that an attack is going to have a signature the same as the previous 'n' hits on that rule, but you want to see the rest of the attack. I don't care to see a scan of the IMAP 1000 times when right after they finish scanning it they also try to attack my POP3 port 1000 times. Rather, I'd rather see the first 100 attempts on the IMAP port, then the first 100 attempts on POP3, then the first 100 attempts on port 7, etc... You get *better* information on per-rule limits than on a global limit. No, you simply get a finer-grained ability to select. If I'm an admin, I'm going to think Well lets see, I want to store a month of bad packets in it. If you're an admin on today's internet, you'd realize that there is *NO* way to get save a month worth of bad packets. Heck, at least once/week I can't even store a day's worth of bad packets (I assume when we say bad packets, we're talking about the If I'm an admin on today's internet (and I am), of course I realize that I'm not going to save a month worth of all bad packets, but I _can_ choose to hold onto a reasonable amount of logging information, which is what we are discussing. That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it allows you to sample the beginning of each 5 minute period, and you ought to be able to calculate the space required in a manner that allows you to guarantee that you have sufficient space. Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 10, and you reset the counter every 5 minutes, you still _ought_ to be able to determine that you require 2GB of disk space per day to keep those records. (And if you're getting 100K rejectable packets every 5 minutes, something is seriously wrong) I zero my counters every five minutes and there is a limit of 100 per five mins, and the average line length is 80 (or whatever) so therefore I need 80 * 100 * 12 * 24 * 30 or 70MB for my worst case scenario. Not. If the attack is the same, then the syslog error reporting will same something like (this is a real message, with IP addresses change to protect the guilty..): Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 Jun 29 16:43:44 ns last message repeated 3 times If you've got seperate attacks, then you've got too much stuff you're logging. Now given 200 rules, I can fill his disk in substantially less than a day. If you're logging that much information, then you're logging too much information. In any case, you've got information overload, so adding a global limit on the rules means you're losing as much (or more) information than you're logging, which is just as bad (or worse). No. You're not necessarily logging too much information. I do log a whole bunch of shouldn't-happen scenarios, because if they do happen, it means something is either horribly broken or somebody is doing something horribly wrong. I don't want an event such as an outbound source 10-net address to happen... in theory it can't because I filter at my borders and use no 10-net stuff internally. But I damn well want to know if it happens ANYWAYS. If you're worried about logging too much information, then don't reset your counters every 5 minutes. Besides, you're losing information if you're max'd out every 5 minutes anyway, so it really doesn't matter when you zero out your counters. You just argued my point for me, thank you. I _want_ to see the things that I choose to log, and by definition once I
Re: file(1) Magdir candidate: wintendo
In the last episode (Jul 26), Sheldon Hearn said: On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: You could start with WinEXE. Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? What about multi-OS games, like Quake? How about just calling it games ? -- Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
hot-swapping ata disks
Hi, I tried 'camcontrol rescan' and I found it works when I add a SCSI device while the system is on. I find it useful for adding/removing devices w/o restarting the box. (Maybe it's risky, but useful. I supposed that's the idea of the 'rescan' command in camcontrol) Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI anyway). Or maybe i'm walking on a wrong way? --iani To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: hot-swapping ata disks
[ I don't know about the IDE code, but I can say something about the SCSI code. ] Iani Brankov wrote... Hi, I tried 'camcontrol rescan' and I found it works when I add a SCSI device while the system is on. I find it useful for adding/removing devices w/o restarting the box. (Maybe it's risky, but useful. I supposed that's the idea of the 'rescan' command in camcontrol) Hot-swapping SCSI devices may or may not be risky. It really depends on your bus topology and whether your setup was designed for it. In general, it's best to only do it in a hot-swap chassis. You can also do it with more conventional cable layouts, provided you don't end up disabling termination or taking something off the bus while I/O is going to it, etc. I wrote a fair bit of the hot swap code with an external CDROM drive in the middle of a terminated external chain. The drive stayed on the chain at all times, but I turned it off and on to make it go away and come back between rescans. Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI anyway). I dunno about the IDE code, although I'm sure Soren will have an answer. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: file(1) Magdir candidate: wintendo
At 05:02 PM 7/26/99 -0500, Dan Nelson wrote: In the last episode (Jul 26), Sheldon Hearn said: On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: You could start with WinEXE. Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? What about multi-OS games, like Quake? How about just calling it games ? How about the obvious: svgames --larry To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
XFree 3.3.4 not on ftp.freebsd.org?
I was trying in vain today to get X 3.3.4 installed on my new system and couldn't seem to make it happen using sysinstall, even after I rebuilt it. AFAICS, there is no XFree 3.3.4 package available on ftp.freebsd.org/pub/FreeBSD, but I may have missed something. Fortunately it is on wcarchive, so I just pulled down all the bits and installed it the hard way, however I know I'm going to run into trouble down the road when ports start looking for the X stuff in /var/db/pkg. Any comments or suggestions welcome, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: VMWare plug/quickie tests.
I just wish that it was the other way around. I'd actually run NT if I could get it in a VMWare compartment under FreeBSD. You would do well to pass these sentiments on to vmware; they're currently counting noses in FreeBSD-land to see if it makes market sense. All the techs there appear to be sold on the idea, but it takes more than tech buy-in to get a project approved. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, Jul 26, 1999 at 05:29:20PM -0700, Doug wrote: and installed it the hard way, however I know I'm going to run into trouble down the road when ports start looking for the X stuff in /var/db/pkg. I seem to remember that you can get away with a simple mkdir /var/db/pkg/xxx to fake it. Alternatively, $ cd /usr/ports/x11/XFree86 ; make generate-plist fake-pkg should be a little more correct. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Free BSDI CD!
Hi, I am not sure whether this is known to this list or not, but here is the URL for ordering: http://www.bsdi.com/products/evalcd/ _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
Instead of zeroing it, how about raising the logging limit to (current + whatever the limit was) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
:Instead of zeroing it, how about raising the logging limit to (current + :whatever the limit was) : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : gr...@freebsd.org _ __ ___ | _ ) __| \ The way I see it either some piece of software is monitor the counters, in which case the sysad does not need to clear them and does not need to look at log messages, or the sysad is monitoring the stuff manually and using the log messages. In the one case the counters don't need to be cleared (and, indeed, should not be), in the other case the sysad may want to clear them due to the manual monitoring. What we are really discussing here is the use of ipfw's counters in an unsophisticated setup. The sophisticated setup is already handled. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
On Mon, 26 Jul 1999, Matthew Dillon wrote: :Instead of zeroing it, how about raising the logging limit to (current + :whatever the limit was) : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : gr...@freebsd.org _ __ ___ | _ ) __| \ The way I see it either some piece of software is monitor the counters, in which case the sysad does not need to clear them and does not need to look at log messages, or the sysad is monitoring the stuff manually and using the log messages. In the one case the counters don't need to be cleared (and, indeed, should not be), in the other case the sysad may want to clear them due to the manual monitoring. What we are really discussing here is the use of ipfw's counters in an unsophisticated setup. The sophisticated setup is already handled. That doesn't mean we shouldn't allow people to have an unsophisticated setup, just because a sophisticated one is available. It would be useful to have a per-firewall-rule counter, decrement it on each match if logging and set, and be able to reset to something higher. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-ipfw in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999, Sheldon Hearn wrote: On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: You could start with WinEXE. Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? No. How about savegames? The Quake 2 format in there would be nice, to distinguish between Q2 Windows version X.XX and Linux glibc, Linux libc5, etc... Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
:That doesn't mean we shouldn't allow people to have an unsophisticated setup, :just because a sophisticated one is available. It would be useful to have :a per-firewall-rule counter, decrement it on each match if logging and :set, and be able to reset to something higher. : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ There may be some confusion here. I am advocating that we *allow* the zeroing of counters at secure level 3. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Free BSDI CD!
On Mon, 26 Jul 1999, Rayson Ho wrote: Hi, I am not sure whether this is known to this list or not, but here is the URL for ordering: http://www.bsdi.com/products/evalcd/ But we can install from a single downloaded boot floppy, over the Internet, which is better. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
On Mon, 26 Jul 1999, Matthew Dillon wrote: :That doesn't mean we shouldn't allow people to have an unsophisticated setup, :just because a sophisticated one is available. It would be useful to have :a per-firewall-rule counter, decrement it on each match if logging and :set, and be able to reset to something higher. : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ There may be some confusion here. I am advocating that we *allow* the zeroing of counters at secure level 3. Which is what I am advocating against. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-ipfw in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
I like the ability at secure level 3 to only reset the counters forward.. It fits in with such things as the append only flag. Maybe a new keyword. advance julian On Mon, 26 Jul 1999, Brian F. Feldman wrote: On Mon, 26 Jul 1999, Matthew Dillon wrote: :That doesn't mean we shouldn't allow people to have an unsophisticated setup, :just because a sophisticated one is available. It would be useful to have :a per-firewall-rule counter, decrement it on each match if logging and :set, and be able to reset to something higher. : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ There may be some confusion here. I am advocating that we *allow* the zeroing of counters at secure level 3. Which is what I am advocating against. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-ipfw in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: securelevel and ipfw zero
: : : :That doesn't mean we shouldn't allow people to have an unsophisticated setup, : :just because a sophisticated one is available. It would be useful to have : :a per-firewall-rule counter, decrement it on each match if logging and : :set, and be able to reset to something higher. : : : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : : There may be some confusion here. I am advocating that we *allow* the : zeroing of counters at secure level 3. : :Which is what I am advocating against. Let me put it a different way: ipfw allows you to clear counters. It is a feature that already exists. However, it does not allow you to do it if you are sitting at secure level 3. Why not? I can't think of any good reason why clearing the counters should be disallowed when sitting at a higher secure level. The counters are nothing more then statistics. Clearing statistics is not a security threat. The discussion should simply be about that. Not all this garbage about adding new features. There's a feature that does not seem to impact security, secure level disallows it, why? -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Free BSDI CD!
In message pine.bsf.4.10.9907262321180.35843-100...@janus.syracuse.net Brian F. Feldman writes: : But we can install from a single downloaded boot floppy, over the : Internet, which is better. Is that still true? I thought we went back to two floppies to do this... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
