From owner-freebsd-security Sun Nov 3 11:05:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA15338 for security-outgoing; Sun, 3 Nov 1996 11:05:01 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA15318 for ; Sun, 3 Nov 1996 11:04:42 -0800 (PST) Received: (from narvi@localhost) by haldjas.folklore.ee (8.7.5/8.6.12) id VAA11072; Sun, 3 Nov 1996 21:05:56 +0200 (EET) Date: Sun, 3 Nov 1996 21:05:55 +0200 (EET) From: Narvi To: Mikael Karpberg cc: Mark Newton , freebsd-security@FreeBSD.org Subject: Re: chroot() security In-Reply-To: <199611030511.GAA14093@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 3 Nov 1996, Mikael Karpberg wrote: > According to Mark Newton: > [...] > > Note that I'm not suggesting this as something that should be added to > > FreeBSD per se; Rather, I'm suggesting that users of FreeBSD in security- > > critical environments can benefit from having kernel sources by taking > > the opportunity to "harden" their kernel. Those who make the attempt > > will find that once their security policy has been codified in written form, > > translating that written form to source code is surprisingly easy > > (interdependencies and subtle interrelationships notwithstanding - Be > > careful!). The suggestion given above, for example, can be implemented > > with just a few lines of C. > > (Gives me some ideas. Thought I'd share them.) > > Why not? Make an option for it in the LINT file, and just #ifdef it? > > option SAFER_CHROOT #Warning, this might break some executables. > > Something like it, at least? Yes. Something like that would be nice (at least as an oppourturity. > Or maybe make some sysclt or something where you can set it on a per > process basis? proc_no_chroot - don't allow the process and any of it's children chroot proc_no_setuid - don't allow the process and any of it's children call setuid - breaks all setuid programs which "give up" their privileges (login, etc.) proc_no_setuidp - don't allow the process and it's children exec setuid programs (in case there are some) - breaks ping, login etc. Would allow you to make login accounts with different levels of restrictions. Whetever any of these would be worth it is another question. Sander > And/Or have a safer_chroot() or no_setuid_chroot() lib call that lets you > add a FreeBSD specific (unless this is copied to other OSes) patch in ports, > etc to make some programs more secure? > > I have no idea how braindamaged any of these ideas are, and for what reason, > but I thought I'd see the reactions on this. > > /Mikael > From owner-freebsd-security Sun Nov 3 12:09:02 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA18983 for security-outgoing; Sun, 3 Nov 1996 12:09:02 -0800 (PST) Received: from www.trifecta.com (www.trifecta.com [206.245.150.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA18969 for ; Sun, 3 Nov 1996 12:08:52 -0800 (PST) Received: (from dev@localhost) by www.trifecta.com (8.7.5/8.6.12) id PAA03641; Sun, 3 Nov 1996 15:01:32 -0500 (EST) Date: Sun, 3 Nov 1996 15:01:32 -0500 (EST) From: Dev Chanchani To: Marc Slemko cc: freebsd-security@FreeBSD.org Subject: Re: chroot() security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > telnetd@192.168.0.1 : \ > .example.com : \ > rfc931 : severity auth.info : \ > twist = /usr/sbin/chroot /directory/to/chroot/to /usr/libexec/telnetd Trying this method, I am getting the error telnetd: all network ports in use. I am sure all network ports are not in use :) any ideas? Thanks in advance. From owner-freebsd-security Sun Nov 3 12:26:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA20008 for security-outgoing; Sun, 3 Nov 1996 12:26:55 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA20001 for ; Sun, 3 Nov 1996 12:26:42 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id NAA06180; Sun, 3 Nov 1996 13:25:25 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id NAA05850; Sun, 3 Nov 1996 13:23:15 -0700 (MST) Date: Sun, 3 Nov 1996 13:23:14 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Dev Chanchani cc: freebsd-security@FreeBSD.org Subject: Re: chroot() security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Check your ptys, ie. /dev/ttyp*. Be sure you have enough of them created in the chrooted /dev/. It may want an /etc/ttys too. When all else fails, do something like add a sleep in there before the telnetd is run and then do a ktrace -i on the process and see what it tries to open just before it dies. On Sun, 3 Nov 1996, Dev Chanchani wrote: > > telnetd@192.168.0.1 : \ > > .example.com : \ > > rfc931 : severity auth.info : \ > > twist = /usr/sbin/chroot /directory/to/chroot/to /usr/libexec/telnetd > > Trying this method, I am getting the error telnetd: all network ports in > use. > > I am sure all network ports are not in use :) > > any ideas? > > Thanks in advance. > From owner-freebsd-security Sun Nov 3 15:31:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA11673 for security-outgoing; Sun, 3 Nov 1996 15:31:54 -0800 (PST) Received: from offensive.communica.com.au (offensive-eth1.adl.communica.com.au [192.82.222.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA11006 for ; Sun, 3 Nov 1996 15:25:13 -0800 (PST) Received: from communica.com.au (frenzy.communica.com.au [192.82.222.65]) by offensive.communica.com.au (8.7.6/8.7.3) with SMTP id JAA21657; Mon, 4 Nov 1996 09:55:23 +1030 (CST) Received: by communica.com.au (4.1/SMI-4.1) id AA13474; Mon, 4 Nov 96 09:48:49 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9611032318.AA13474@communica.com.au> Subject: Re: chroot() security To: dev@trifecta.com (Dev Chanchani) Date: Mon, 4 Nov 1996 09:48:49 +1030 (CST) Cc: marcs@znep.com, freebsd-security@freebsd.org In-Reply-To: from "Dev Chanchani" at Nov 3, 96 03:01:32 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dev Chanchani wrote: > > telnetd@192.168.0.1 : \ > > .example.com : \ > > rfc931 : severity auth.info : \ > > twist = /usr/sbin/chroot /directory/to/chroot/to /usr/libexec/telnetd > > Trying this method, I am getting the error telnetd: all network ports in > use. You've probably installed tcpd with the "simple" option, which involves replacing your daemons in /usr/libexec/ with a hard link to tcpd, which knows where to find the "real" ones if a connection is permitted. Hence, when you call /usr/libexec/telnetd in the example above, it ends up running recursively. This is probably not what you want :-) Try specifying the path to the "real" telnetd instead (the one in your hide directory, which was configured into tcpd at compile time). > I am sure all network ports are not in use :) I'm willing to believe they are :-) (they'll be mostly in CLOSE_WAIT though) - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Sun Nov 3 15:32:44 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA11868 for security-outgoing; Sun, 3 Nov 1996 15:32:44 -0800 (PST) Received: from s4.elec.uq.edu.au (clary@s4.elec.uq.edu.au [130.102.96.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA11857 for ; Sun, 3 Nov 1996 15:32:33 -0800 (PST) Received: (from clary@localhost) by s4.elec.uq.edu.au (8.7.5/8.6.12) id JAA07164; Mon, 4 Nov 1996 09:31:04 +1000 (EST) From: Clary Harridge Message-Id: <199611032331.JAA07164@s4.elec.uq.edu.au> Subject: Re: /etc/security To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Mon, 4 Nov 1996 09:31:03 +1000 (EST) Cc: freebsd-security@FreeBSD.org In-Reply-To: <199611011141.MAA08439@ocean.campus.luth.se> from "Mikael Karpberg" at Nov 1, 96 12:41:41 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > ---- > > According to Garrett Wollman: > > < [... on the find job not handling ' characters either ...] > > >> checking setuid files and devices: > > >> find: /doscopy/sb16/pro_org/i'vebeen.org: illegal path > > >> find: /doscopy/sb16/pro_org/she'llbe.org: illegal path > > > > The best way to deal with this is probably using the `-print0' primary > > to `find' and using a `perl -n0' script to process the results, like: > > > > find ..... -print0 | perl -n0e 'exec "/bin/ls", "-lFgod", <>;' > > Would this solve the spaces problem too, and any other eventualities? > It may do but I don't think it is necessary. The problem is the -X switch of find, why use xargs anyway. The task of the find is to just ls any suid/sgid files. Why complicate it? from the find manual page -X The -X option is a modification to permit find to be safely used in conjunction with xargs(1). If a file name contains any of the delimiting characters used by xargs, a diagnostic message is displayed on standard error, and the file is skipped. The delim- iting characters include single (`` ' '') and double (`` " '') quotes, backslash (``\''), space, tab and newline characters. I read this to say that any suid file with a blank, or other delimiter, in the name will create an error but be skipped from the output. For example s5:/tmp # touch "Name with space" s5:/tmp # chmod 4777 !$ chmod 4777 "Name with space" s5:/tmp # ll !$ ll "Name with space" 0 -rwsrwxrwx 1 root bin 0 Nov 1 09:00 Name with space s5:/tmp # find -X . -xdev -type f \ \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \ \( -perm -u+s -or -perm -g+s \) ? \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \ ? \( -perm -u+s -or -perm -g+s \) find: ./Name with space: illegal path s5:/tmp # s5:/tmp # find . -xdev -type f \ \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \ \( -perm -u+s -or -perm -g+s \) -a -exec ls -lgTd {} ";" ? \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \ ? \( -perm -u+s -or -perm -g+s \) -a -exec ls -lgTd {} ";" -rwsrwxrwx 1 root bin 0 Nov 1 09:00:04 1996 ./Name with space So let's keep it simple. -- regards Dept. of Electrical Engineering, Clary Harridge University of Queensland, QLD, Australia, 4072 Phone: +61-7-3365-3636 Fax: +61-7-3365-4999 INTERNET: clary@elec.uq.edu.au From owner-freebsd-security Sun Nov 3 15:42:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA12842 for security-outgoing; Sun, 3 Nov 1996 15:42:34 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA12592 for ; Sun, 3 Nov 1996 15:39:50 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id KAA01481; Mon, 4 Nov 1996 10:38:58 +1100 (EST) Date: Mon, 4 Nov 1996 10:38:55 +1100 (EST) From: "Daniel O'Callaghan" To: Dev Chanchani cc: Marc Slemko , freebsd-security@freebsd.org Subject: Re: chroot() security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 3 Nov 1996, Dev Chanchani wrote: > > telnetd@192.168.0.1 : \ > > .example.com : \ > > rfc931 : severity auth.info : \ > > twist = /usr/sbin/chroot /directory/to/chroot/to /usr/libexec/telnetd I achieved the same result by adding a switch -switchbyip to work with -chroot switch in the Firewall Toolkit netacl.c. Simply appends the ip address to the target chroot directory, so /chroot -> /chroot/192.3.4.5 netacl.c *does* chdir() before chroot()ing. Also, a couple of years ago this sort of stuff was discussed on firewalls@greatcircle.com. I think it was Marcus Ranum, author of FWTK, who posted a fix for the unchroot problem. Essentially: there is one root inode, which is normally 0. After a chroot() it is no longer 0. If you wish to prevent all processes from breaking out of a chroot()ed area, it is simple to deny chroot() calls to processes which have root inode != 0. I'm not a FS hacker, and it is two years since I read the posting, but I think you'll get the idea. I think this is similar to PHK's posting, apart from the killing of the process. The code to do the above is about 2 lines, from my hazy memory. This hardening is good, but it has its limitations. ftpd which has been run prechroot()ed, cannot operate as anonymous (or if wu-ftpd as a guest-class user) because it cannot chroot() again. Probably not an insurmountable problem, but it does limit the usefulness of the 'fix' described above. Can anyone think of a way to determine whether a chroot() is "upwards" or "downwards"? It would be nice to be able to allow chroot()s deeper into the tree, but not "upwards". Danny From owner-freebsd-security Sun Nov 3 19:09:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA02254 for security-outgoing; Sun, 3 Nov 1996 19:09:01 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA02245 for ; Sun, 3 Nov 1996 19:08:55 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id TAA10244; Sun, 3 Nov 1996 19:07:36 -0800 (PST) From: Don Lewis Message-Id: <199611040307.TAA10244@salsa.gv.ssi1.com> Date: Sun, 3 Nov 1996 19:07:36 -0800 In-Reply-To: "Daniel O'Callaghan" "Re: chroot() security" (Nov 4, 10:38am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Daniel O'Callaghan" , Dev Chanchani Subject: Re: chroot() security Cc: Marc Slemko , freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 4, 10:38am, "Daniel O'Callaghan" wrote: } Subject: Re: chroot() security } } Also, a couple of years ago this sort of stuff was discussed on } firewalls@greatcircle.com. I think it was Marcus Ranum, author of FWTK, } who posted a fix for the unchroot problem. Essentially: there is } one root inode, which is normally 0. After a chroot() it is no longer } 0. If you wish to prevent all processes from breaking out of a } chroot()ed area, it is simple to deny chroot() calls to processes which } have root inode != 0. Yes, this is one possible fix ... } This hardening is good, but it has its limitations. ftpd which has been } run prechroot()ed, cannot operate as anonymous (or if wu-ftpd as a } guest-class user) because it cannot chroot() again. Probably not an } insurmountable problem, but it does limit the usefulness of the 'fix' } described above. and this is it's biggest problem. } Can anyone think of a way to determine whether a chroot() is "upwards" } or "downwards"? It would be nice to be able to allow chroot()s deeper } into the tree, but not "upwards". This isn't secure against the exploit by cooperating processes that I posted a couple days ago. One process can do a chroot() deeper into the tree and chdir() to a subdirectory of that directory, then the other process can rename() that directory outside the tree under the first process' root directory. The most flexible and secure fix would be to treat the root directory as an append-only list. Pathname translations starting with / would use the last list entry, and upward movement using "..", would stop when encountering any members of the list. Of course, there are other potential problems unless you limit the length of the list. I implemented something equivalent to this with a fixed list length of two. --- Truck From owner-freebsd-security Sun Nov 3 19:14:19 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA02563 for security-outgoing; Sun, 3 Nov 1996 19:14:19 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA02556 for ; Sun, 3 Nov 1996 19:14:14 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id TAA10255; Sun, 3 Nov 1996 19:13:15 -0800 (PST) From: Don Lewis Message-Id: <199611040313.TAA10255@salsa.gv.ssi1.com> Date: Sun, 3 Nov 1996 19:13:09 -0800 In-Reply-To: Mikael Karpberg "Re: chroot() security" (Nov 3, 6:11am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Mikael Karpberg , newton@communica.com.au (Mark Newton) Subject: Re: chroot() security Cc: freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 3, 6:11am, Mikael Karpberg wrote: } Subject: Re: chroot() security } } Why not? Make an option for it in the LINT file, and just #ifdef it? } } option SAFER_CHROOT #Warning, this might break some executables. } } Something like it, at least? } Or maybe make some sysclt or something where you can set it on a per } process basis? I've implemented something like this with a config option that adds code that disables a number of things for chroot()ed processes if a certain sysctl variable is set. I'm now glad that I can turn this off with sysctl because there have been some things that I've needed to do that I couldn't do in "safer" mode. --- Truck From owner-freebsd-security Sun Nov 3 19:19:19 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA02915 for security-outgoing; Sun, 3 Nov 1996 19:19:19 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA02910 for ; Sun, 3 Nov 1996 19:19:15 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id TAA10265; Sun, 3 Nov 1996 19:18:38 -0800 (PST) From: Don Lewis Message-Id: <199611040318.TAA10265@salsa.gv.ssi1.com> Date: Sun, 3 Nov 1996 19:18:36 -0800 In-Reply-To: newton@communica.com.au (Mark Newton) "Re: chroot() security" (Nov 3, 4:36am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: newton@communica.com.au (Mark Newton), Don.Lewis@tsc.tdk.com (Don Lewis) Subject: Re: chroot() security Cc: marcs@znep.com, dev@trifecta.com, freebsd-security@FreeBSD.org Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Nov 3, 4:36am, Mark Newton wrote: } Subject: Re: chroot() security } Don Lewis wrote: } } > BTW, thanks for mentioning ptrace(). I hadn't thought of that one. } } There's a far more obvious one: The same data structures and library } routines which provide "ps" with its ability to find the process table in } kvm space can permit an attacker with root privileges in a chroot()'ed } environment to find the process table for the purpose of changing his } root directory right back to what it used to be by reading and writing } /dev/kmem. You're correct, that one is more obvious. Writes to /dev/kmem can be used for other evil things as well. The obvious fixes are to do one or more of the following: Don't put /dev/kmem within reach of the chroot()ed process. Turn on securelevel, which I believe prohibits writes to /dev/kmem, even by root. --- Truck From owner-freebsd-security Sun Nov 3 19:28:29 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA03698 for security-outgoing; Sun, 3 Nov 1996 19:28:29 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA03681 for ; Sun, 3 Nov 1996 19:28:25 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id TAA10276; Sun, 3 Nov 1996 19:27:55 -0800 (PST) From: Don Lewis Message-Id: <199611040327.TAA10276@salsa.gv.ssi1.com> Date: Sun, 3 Nov 1996 19:27:55 -0800 In-Reply-To: Poul-Henning Kamp "Re: chroot() security" (Nov 2, 10:38am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Poul-Henning Kamp , Marc Slemko Subject: Re: chroot() security Cc: Don Lewis , Dev Chanchani , freebsd-security@FreeBSD.ORG Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 2, 10:38am, Poul-Henning Kamp wrote: } Subject: Re: chroot() security } In message , Marc Sl } emko writes: } >Yup, you certainly can add checks and in theory you should be able to plug } >all the holes IF you can find them. My bet is that you won't be able to } >find them, so you can't make it secure. } } One simple way is to disallow processes that have any *uid == 0 in the } chroot tree. I did this once by comparing the rootfs pointer to that } of pid == 1 and if it was different and one of the uid's were zero } I killed the process. } } The few operations that needed to do root things, sent a message over } a tcp pipe to a local process that would examine what process was at the } other end of the pipe and do the stuff to it if it made sense. That } daemon ran outside the chroot env. I'm not convinced this is more secure. It may be possible for the chroot()ed process to trick the non-chroot()ed process into doing something bad, perhaps by following a /some/path/outside/chroot symlink that the chroot()ed process created in the chroot() environment. If the root process was also chroot()ed, then the damage it does would be contained within that environment, unless it could be tricked into arbitrary code (via a buffer overflow exploit, etc.) to get it out of that environment. If the latter is possible, then you're already in deeper yogurt if the root process is not chroot()ed. --- Truck From owner-freebsd-security Mon Nov 4 10:44:44 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA12962 for security-outgoing; Mon, 4 Nov 1996 10:44:44 -0800 (PST) Received: from itchy.atlas.com ([206.29.170.246]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA12954 for ; Mon, 4 Nov 1996 10:44:40 -0800 (PST) Received: (from brantk@localhost) by itchy.atlas.com (8.8.0/8.8.0) id KAA15255; Mon, 4 Nov 1996 10:45:38 -0800 (PST) From: Brant Katkansky Message-Id: <199611041845.KAA15255@itchy.atlas.com> Subject: Re: chroot() security To: newton@communica.com.au (Mark Newton) Date: Mon, 4 Nov 1996 10:45:37 -0800 (PST) Cc: Don.Lewis@tsc.tdk.com, marcs@znep.com, dev@trifecta.com, freebsd-security@FreeBSD.org In-Reply-To: <9611021806.AA19481@communica.com.au> from Mark Newton at "Nov 3, 96 04:36:41 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Note that I'm not suggesting this as something that should be added to > FreeBSD per se; Rather, I'm suggesting that users of FreeBSD in security- > critical environments can benefit from having kernel sources by taking > the opportunity to "harden" their kernel. How 'bout making it a compile-time option? -- Brant Katkansky (brantk@atlas.com) Software Engineer, ADC From owner-freebsd-security Mon Nov 4 14:50:04 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA08864 for security-outgoing; Mon, 4 Nov 1996 14:50:04 -0800 (PST) Received: from offensive.communica.com.au (offensive-eth1.adl.communica.com.au [192.82.222.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA08834 for ; Mon, 4 Nov 1996 14:49:55 -0800 (PST) Received: from communica.com.au (frenzy.communica.com.au [192.82.222.65]) by offensive.communica.com.au (8.7.6/8.7.3) with SMTP id JAA24050; Tue, 5 Nov 1996 09:20:31 +1030 (CST) Received: by communica.com.au (4.1/SMI-4.1) id AA09752; Tue, 5 Nov 96 09:13:46 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9611042243.AA09752@communica.com.au> Subject: Re: chroot() security To: brantk@atlas.com (Brant Katkansky) Date: Tue, 5 Nov 1996 09:13:46 +1030 (CST) Cc: newton@communica.com.au, Don.Lewis@tsc.tdk.com, marcs@znep.com, dev@trifecta.com, freebsd-security@FreeBSD.org In-Reply-To: <199611041845.KAA15255@itchy.atlas.com> from "Brant Katkansky" at Nov 4, 96 10:45:37 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Brant Katkansky wrote: > > Note that I'm not suggesting this as something that should be added to > > FreeBSD per se; Rather, I'm suggesting that users of FreeBSD in security- > > critical environments can benefit from having kernel sources by taking > > the opportunity to "harden" their kernel. > > How 'bout making it a compile-time option? I think some people are missing the point. The kind of "security-conscious" environment I'm talking about is something like a firewall or a very restricted access system. Now, in both of those situations, it is expected that the organization that is running the system has some kind of written (or otherwise) policy to determine how that system is treated. That policy more or less defines exactly how secure that system is going to be by specifying the rights and privileges of the system itself and the users who login to it (if any) One of the things that can be done on that system is to hack the kernel to enforce the policy in software -- That way you have to trust the system a little bit less, because your software enforces your policy for you. Each organization will have their own security policy. We cannot, ahead of time, say, "Yeah, everyone will want this." Thus, putting these hacks in as compile-time options is not appropriate: it'll only ever lead to bloat which very few people (those who agree with your particular policy) will take advantage of. On the other hand, some kind of FAQ might be useful to make sure that people are aware of the potential that the presence of source code provides for them. If that's publicized then people are free to make their own hacks to enforce their own policies. Cheers, - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Mon Nov 4 23:48:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA13464 for security-outgoing; Mon, 4 Nov 1996 23:48:26 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA13459 for ; Mon, 4 Nov 1996 23:48:23 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id BAA17765; Tue, 5 Nov 1996 01:17:43 +0100 (MET) From: Mikael Karpberg Message-Id: <199611050017.BAA17765@ocean.campus.luth.se> Subject: Re: chroot() security To: newton@communica.com.au (Mark Newton) Date: Tue, 5 Nov 1996 01:15:12 +0100 (MET) Cc: freebsd-security@FreeBSD.org In-Reply-To: <9611042243.AA09752@communica.com.au> from Mark Newton at "Nov 5, 96 09:13:46 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Mark Newton: > Brant Katkansky wrote: > > > > Note that I'm not suggesting this as something that should be added to > > > FreeBSD per se; Rather, I'm suggesting that users of FreeBSD in security- > > > critical environments can benefit from having kernel sources by taking > > > the opportunity to "harden" their kernel. > > > > How 'bout making it a compile-time option? > > I think some people are missing the point. > > The kind of "security-conscious" environment I'm talking about is something > like a firewall or a very restricted access system. It's not what I'm talking about. I'm talking about giving people an opportunity to make their system a bit more secure, if it's possible with their setup. > Now, in both of those situations, it is expected that the organization > that is running the system has some kind of written (or otherwise) policy > to determine how that system is treated. That policy more or less > defines exactly how secure that system is going to be by specifying the > rights and privileges of the system itself and the users who login to it > (if any) > > One of the things that can be done on that system is to hack the kernel > to enforce the policy in software -- That way you have to trust the system > a little bit less, because your software enforces your policy for you. > > Each organization will have their own security policy. We cannot, ahead > of time, say, "Yeah, everyone will want this." Thus, putting these hacks > in as compile-time options is not appropriate: it'll only ever lead to > bloat which very few people (those who agree with your particular > policy) will take advantage of. > > On the other hand, some kind of FAQ might be useful to make sure that > people are aware of the potential that the presence of source code > provides for them. If that's publicized then people are free to make > their own hacks to enforce their own policies. "If you can't write a UNIX on your own, you shouldn't use our's either"? I think we should go the other way, making it easier to use FreeBSD. "We can not make FreeBSD perfect for all occations, so why even try?" is not a good way to go, I think. Add a code to make chroot more secure. Make it a compile time option. Then people can choose to use it or not, as it will inevidably bring SOME problem with it, no matter how it's done. The bloat is very small, and only a source-bloat. Not a kernel bloat. An FAQ entry? Yes, ofcourse! Describe how you can use the compile time option, and what problems it brings, and what it solves. Add a hint to the handbook, where you describe what's done why, and suggest alternations depending on need. That way people can change it if they want, with a guiding hand. Step by step instructions, basically. Hacking stuff in the kernel is much worse then crunching a userspace program into exactly what you want it to. Things you do can affect stuff you didn't even know existed, etc. I for one would be very careful about trying to add something like this safer chroot patch. And I wouldn't know were to start. With the option in I can go in and change my config file and try the default. If it's not exactly what I want, then I can look through the files for code that has ifdef for that option, and I can read the FAQ entry, and maybe dare go in and do a small change to that, in it self, small patch (you (?) said it was, at least). Hmm.... Do you see my point? /Mikael From owner-freebsd-security Tue Nov 5 02:10:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA23411 for security-outgoing; Tue, 5 Nov 1996 02:10:56 -0800 (PST) Received: from offensive.communica.com.au (offensive-eth1.adl.communica.com.au [192.82.222.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA23404 for ; Tue, 5 Nov 1996 02:10:48 -0800 (PST) Received: from communica.com.au (frenzy.communica.com.au [192.82.222.65]) by offensive.communica.com.au (8.7.6/8.7.3) with SMTP id UAA25246; Tue, 5 Nov 1996 20:41:18 +1030 (CST) Received: by communica.com.au (4.1/SMI-4.1) id AA21746; Tue, 5 Nov 96 20:34:33 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9611051004.AA21746@communica.com.au> Subject: Re: chroot() security To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Tue, 5 Nov 1996 20:34:32 +1030 (CST) Cc: newton@communica.com.au, freebsd-security@freebsd.org In-Reply-To: <199611050017.BAA17765@ocean.campus.luth.se> from "Mikael Karpberg" at Nov 5, 96 01:15:12 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg wrote: > > On the other hand, some kind of FAQ might be useful to make sure that > > people are aware of the potential that the presence of source code > > provides for them. If that's publicized then people are free to make > > their own hacks to enforce their own policies. > > "If you can't write a UNIX on your own, you shouldn't use our's either"? That's a rather extreme view, dear Sir -- I think both of us know that what I said has born absolutely no resemblance to this rather incandescent straw-man! > I think we should go the other way, making it easier to use FreeBSD. By all means, and I think it *is* easy to use. But we're not talking about something the standard Windows 95 user will be utilizing. Let's put this into perspective: The applications in which that compile-time option will be useful are quite specialized. To even know that chroot() exists requires a certain amount of sophistication as a user (let's face it, it is rather obscure, innit?). Such a specialist application cannot be made foolproof. Unfortunately, if it's easy enough for unsophisticated users (let's call them "plebs" or "peons" :-) to use then it stands a very realistic chance of lulling them into a false sense of security... which is often worse than no security at all. We cannot create the impression that a four-line patch makes FreeBSD "more secure" or "easier" because, put bluntly, it doesn't. For the overwhelming majority of users it'll make not a jot of difference; for those users who would benefit from the difference, they are hopefully sophisticated enough to know that the four-line patch isn't the answer to all their problems, and that they're going to have to invest a lot of time with a lot of source code whether they like it or not. And, if they require the added security and can't comprehend the source code then no accusations of intellectual snobbery will convince me that they are the *wrong* people to be looking after their security. Do you see my point? While it's all very well to make FreeBSD so easy that even a Win95 user can install it, it's something completely different to announce to the world that it's so easy that a Win95 user can be a security expert (god knows, we have enough NT advocates proclaiming themselves to be security experts already! :-) That is why I suggest putting it in the FAQ instead of putting it into the source tree (if you really want to, the patch itself could be put into the FAQ with the explanation). The explanation in the FAQ should make it clear that there is no such thing as a magic cure-all for security problems, and if the user *really* wants security then they should be using an air-gap firewall :-) > "We can not make FreeBSD perfect for all occations, so why even try?" is > not a good way to go, I think. Again, you're drawing out a straw man attack. I think we are trying. I have a patch here which I'm testing at the moment; I'll release it to this list later tonight if I'm happy with it. As well as actual code, we're talking about putting something in the security section of the FAQ and Handbook -- That's hardly "not even [trying]." We cannot allow people to think that they can solve all their security problems and implement all their security policies without exposure to source code, whether in the kernel or in userland. > The bloat is very small, and only a source-bloat. Not a kernel bloat. :-) And thus UNIX grew from a system which would fit onto 20Mb of disk with complete source code into the system we all know and love today > Hacking stuff in the kernel is much worse then crunching a userspace program > into exactly what you want it to. Things you do can affect stuff you didn't > even know existed, etc. That's exactly what we want this one to do :-) This is the kind of thing which is *intended* to break userland programs. It's *intended* to reduce functionality. It's a bit like removing the setuid bit from sendmail and running it as a non-root user: It provides a vast improvement in security for a severe degradation in functionality (local users can't send and receive mail, in that instance, and you have to run its "daemon" functionality out of inetd and cron). In almost all cases, increasing security reduces ease-of-use. It's one of those trade-offs which has had commercial firewall vendors battling with all kinds of user interface paradigms for years. It's the kind of thing that has left us entrenched with broken protocols like rlogin/rsh, disastrously unsecure and yet so enticingly *easy* to use! In general terms, you increase the security of an existing system by disabling or removing those parts of its functionality which are unsecure; yes, there are alternatives which preserve ease of use, but they generally decrease maintainability, which necessarily decreases security. I'm not a great fan of making security easy. I'd rather make it secure. I think I've been talking about two things -- Ease of making it secure and ease of using it afterwards. I hope I haven't obfuscated the issue too much... > I for one would be very careful about trying > to add something like this safer chroot patch. And I wouldn't know were to > start. With the option in I can go in and change my config file and try the > default. If it's not exactly what I want, then I can look through the files > for code that has ifdef for that option, and I can read the FAQ entry, and > maybe dare go in and do a small change to that, in it self, small patch > (you (?) said it was, at least). Ah. So you're saying that if it was nice and easy then you'd go out of your way to spend lots of time and effort on researching it before going ahead and implementing it? Excellent! You have met the prerequisites for using something like this. Yet you expect those who don't meet the prerequisites to just add "options FUNKY_CHROOT" to their kernel config file and "know" that it'll make their system more secure without having the benefit of knowing why? Don't you see the dangers inherent in that approach? > Do you see my point? Absolutely. Do you see mine? - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Tue Nov 5 04:07:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA27884 for security-outgoing; Tue, 5 Nov 1996 04:07:59 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA27875; Tue, 5 Nov 1996 04:07:55 -0800 (PST) Message-Id: <199611051207.EAA27875@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA274375393; Tue, 5 Nov 1996 23:03:13 +1100 From: Darren Reed Subject: Re: ip_fw.c - bug or feature ? To: cliff@st.simbirsk.su (Viacheslav Andreev) Date: Tue, 5 Nov 1996 23:03:13 +1100 (EDT) Cc: freebsd-hackers@freebsd.org, freebsd-security@freebsd.org In-Reply-To: <199611050930.AA26920@mpool.st.simbirsk.su> from "Viacheslav Andreev" at Nov 5, 96 12:30:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Viacheslav Andreev, sie said: > > Hi! > > I am not shure, this is a bug or feature. > While trying to disable tcp traffic for some port, f.e. > > ipfw add 1070 deny log tcp from any to 192.168.0.1 80 > > , there are false dropping of fragmented (i.e. 2-nd and next-s without > tcp port info) packets of ftp traffic. IMHO, it is a result of > matching fragments over firewall rules with tcp port specs : bug. A rule with port fields or TCP flags to match should not match a fragment. Darren From owner-freebsd-security Tue Nov 5 04:33:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA29505 for security-outgoing; Tue, 5 Nov 1996 04:33:58 -0800 (PST) Received: from offensive.communica.com.au (offensive-eth1.adl.communica.com.au [192.82.222.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA29497 for ; Tue, 5 Nov 1996 04:33:48 -0800 (PST) Received: from communica.com.au (frenzy.communica.com.au [192.82.222.65]) by offensive.communica.com.au (8.7.6/8.7.3) with SMTP id XAA25452; Tue, 5 Nov 1996 23:04:22 +1030 (CST) Received: by communica.com.au (4.1/SMI-4.1) id AA23882; Tue, 5 Nov 96 22:57:28 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9611051227.AA23882@communica.com.au> Subject: Re: chroot() security To: newton@communica.com.au (Mark Newton) Date: Tue, 5 Nov 1996 22:57:27 +1030 (CST) Cc: karpen@ocean.campus.luth.se, newton@communica.com.au, freebsd-security@FreeBSD.org In-Reply-To: <9611051004.AA21746@communica.com.au> from "Mark Newton" at Nov 5, 96 08:34:32 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Mark Newton wrote: > And, if they require the added security and can't comprehend the source > code then no accusations of intellectual snobbery will convince me that > they are the *wrong* people to be looking after their security. ^^^aren't! Sense change: I hope I don't write code like that :-) > I think we are trying. I have a patch here which I'm testing at the > moment; I'll release it to this list later tonight if I'm happy with > it. Ok, here's a patch. Comment to your heart' desires. To use it: Apply the patch by using "patch < filename" (beware: absolute filenames in the patch; You may want to edit the headers if your source tree doesn't live in /usr/src and your kernel source isn't reachable as /sys). Edit your kernel config file; add a line which looks like: options "FUNKY_CHROOT" config, make depend, make, make install, reboot. Woo-hoo! I tested it by using a diskless root filesystem I have lying about on one of my disks: Without the patch, the following works: atdot# chroot /export/root/dotat /bin/csh dotat# chroot . /bin/csh dotat# With the patch, I get this: atdot# chroot /export/root/dotat /bin/csh dotat# chroot . /bin/csh chroot: .: Operation not permitted dotat# I've done a few more tests and they seem to work ok; let me know if this is broken (it's fairly simple, but who knows?) - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au *** /usr/src/lib/libc/sys/chroot.2.orig Tue Nov 5 20:55:43 1996 --- /usr/src/lib/libc/sys/chroot.2 Tue Nov 5 22:27:49 1996 *************** *** 60,65 **** --- 60,71 ---- has no effect on the process's current directory. .Pp This call is restricted to the super-user. + .Pp + If the kernel has been built with the FUNKY_CHROOT compile-time option, + then calling chroot(2) will cause all future invocations for the calling + process and all of its future children to fail. In certain circumstances + this behaviour can enhance security; In other circumstances it can + reduce security and cause existing software to break horribly. .Sh RETURN VALUES Upon successful completion, a value of 0 is returned. Otherwise, a value of -1 is returned and *************** *** 72,78 **** .It Bq Er ENOTDIR A component of the path name is not a directory. .It Bq Er EPERM ! The effective user ID is not the super-user. .It Bq Er EINVAL The pathname contains a character with the high-order bit set. .It Bq Er ENAMETOOLONG --- 78,87 ---- .It Bq Er ENOTDIR A component of the path name is not a directory. .It Bq Er EPERM ! The effective user ID is not the super-user, or this kernel has been ! built with FUNKY_CHROOT and a previous call to ! .Xr chroot 2 ! has been made by the caller or one of its ancestors. .It Bq Er EINVAL The pathname contains a character with the high-order bit set. .It Bq Er ENAMETOOLONG *************** *** 90,95 **** --- 99,106 ---- .It Bq Er EIO An I/O error occurred while reading from or writing to the file system. .El + .Sh BUGS + FUNKY_CHROOT is a stupid name. .Sh SEE ALSO .Xr chdir 2 .Sh HISTORY *** /sys/kern/vfs_syscalls.c.orig Tue Nov 5 18:20:22 1996 --- /sys/kern/vfs_syscalls.c Tue Nov 5 20:42:21 1996 *************** *** 607,612 **** --- 607,619 ---- register struct filedesc *fdp = p->p_fd; int error; struct nameidata nd; + #if defined(FUNKY_CHROOT) + register struct proc *init; + + init = pfind((pid_t)1); /* locate init's proc structure */ + if (fdp->fd_rdir != init->p_fd->fd_rdir) + return(EPERM); /* if p's root != init's root return EPERM */ + #endif /* FUNKY_CHROOT */ error = suser(p->p_ucred, &p->p_acflag); if (error) From owner-freebsd-security Wed Nov 6 20:17:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA24815 for security-outgoing; Wed, 6 Nov 1996 20:17:11 -0800 (PST) Received: from iquest.net (iquest4.iquest.net [206.53.230.100]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA24808 for ; Wed, 6 Nov 1996 20:17:07 -0800 (PST) Received: from drifter.iquest.net by iquest.net with smtp (Smail3.1.29.1 #5) id m0vLLti-003ijWC; Wed, 6 Nov 96 23:16 EST Message-ID: <32816280.41C67EA6@iquest.net> Date: Wed, 06 Nov 1996 23:16:00 -0500 From: Jerry Kelley X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Anyone have info on IP Filter build & install for FreeBSD? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm looking at the IP Filter program and am wondering if anyone has got it up and running with FreeBSD. If so, I'd like just a few brief hints on the instructions from the INSTALL.xBSD file that comes with it. Are there any changes to this info for FreeBSD or can I just follow the info in there "as-is" without modification? Is there anywhere I can get more info on IP Filter? Are there any web pages that have some links to docs or any other info that might be of use? Thanks in advance. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jerry Kelley jerryk@iquest.net "Expectations are life's greatest dangers." From owner-freebsd-security Wed Nov 6 21:14:15 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA28089 for security-outgoing; Wed, 6 Nov 1996 21:14:15 -0800 (PST) Received: from ilms.nla.gov.au (ilms.nla.gov.au [192.102.239.30]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA28075 for ; Wed, 6 Nov 1996 21:14:10 -0800 (PST) Received: from gadget.nla.gov.au (cmakin@gadget.nla.gov.au [203.4.201.52]) by ilms.nla.gov.au (8.6.12/8.6.12) with SMTP id QAA99474; Thu, 7 Nov 1996 16:10:09 +1100 Date: Thu, 7 Nov 1996 16:14:00 +1100 (EST) From: Carl Makin To: Jerry Kelley cc: freebsd-security@freebsd.org Subject: Re: Anyone have info on IP Filter build & install for FreeBSD? In-Reply-To: <32816280.41C67EA6@iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 6 Nov 1996, Jerry Kelley wrote: > I'm looking at the IP Filter program and am wondering if anyone has got > it up and running with FreeBSD. If so, I'd like just a few brief hints I'm using it on FreeBSD 2.1.5R. > on the instructions from the INSTALL.xBSD file that comes with it. Are > there any changes to this info for FreeBSD or can I just follow the > info in there "as-is" without modification? Just follow the docs. I haven't tried the kernel install but the module install works well. I'm mainly using the NAT features to gateway my home subnet out. The kernel compile after doing the "minstall" is necessary. Don't forget it. and before anyone spits I'm also using squidcache and socks. There are some things that arn't socksified. > Is there anywhere I can get more info on IP Filter? Are there any web > pages that have some links to docs or any other info that might be of > use? Try; http://coombs.anu.edu.au/~avalon/ip-filter.html it's the home page for it. Carl. -- Carl Makin (VK1KCM) C.Makin@nla.gov.au 'Work +61 6 262 1576' "Speaking for myself only!" 'If you want to make your spouse pay attention to what you say... Talk in your sleep!' From owner-freebsd-security Wed Nov 6 21:26:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA29075 for security-outgoing; Wed, 6 Nov 1996 21:26:45 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA29069 for ; Wed, 6 Nov 1996 21:26:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id WAA21465; Wed, 6 Nov 1996 22:26:33 -0700 Message-Id: <199611070526.WAA21465@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Jerry Kelley cc: freebsd-security@FreeBSD.org Subject: Re: Anyone have info on IP Filter build & install for FreeBSD? In-reply-to: Your message of "Wed, 06 Nov 1996 23:16:00 EST." <32816280.41C67EA6@iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 22:26:33 -0700 Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Is there anywhere I can get more info on IP Filter? Are there any web > pages that have some links to docs or any other info that might be of > use? http://coombs.anu.edu.au/~avalon/ip-filter.html -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-security Wed Nov 6 21:34:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA29514 for security-outgoing; Wed, 6 Nov 1996 21:34:34 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA29491 for ; Wed, 6 Nov 1996 21:34:14 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id QAA08069; Thu, 7 Nov 1996 16:33:12 +1100 (EST) Date: Thu, 7 Nov 1996 16:33:10 +1100 (EST) From: "Daniel O'Callaghan" To: Jerry Kelley cc: freebsd-security@freebsd.org Subject: Re: Anyone have info on IP Filter build & install for FreeBSD? In-Reply-To: <32816280.41C67EA6@iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 6 Nov 1996, Jerry Kelley wrote: > I'm looking at the IP Filter program and am wondering if anyone has got > it up and running with FreeBSD. If so, I'd like just a few brief hints > on the instructions from the INSTALL.xBSD file that comes with it. Are > there any changes to this info for FreeBSD or can I just follow the > info in there "as-is" without modification? Use it as-is, except that with 2.1.5 you need to adjust the patched /sys/netinet/ip_input.c so that the ipfw hook comes *after* the ipfilter hook instead of before. If you don't do that, NAT does not work. I've been meaning to point this out to Darren. > Is there anywhere I can get more info on IP Filter? Are there any web > pages that have some links to docs or any other info that might be of > use? http://coombs.anu.edu.au/~avalon/ Are you looking to use the filter part or the NAT part? Danny From owner-freebsd-security Fri Nov 8 10:01:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA26421 for security-outgoing; Fri, 8 Nov 1996 10:01:47 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA26411 for security; Fri, 8 Nov 1996 10:01:45 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199611081801.KAA26411@freefall.freebsd.org> Subject: urgent! SYN packet flood tolerance in 2.1.5? (fwd) To: security Date: Fri, 8 Nov 1996 10:01:44 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ian Kallen wrote: >From ian@ns1.gamespot.com Thu Nov 7 14:36:56 1996 Message-Id: <199611071325.NAA25683@gamespot.com> Comments: Authenticated sender is From: "Ian Kallen" To: jmb@freebsd.org Date: Thu, 7 Nov 1996 12:39:33 +0000 Subject: urgent! SYN packet flood tolerance in 2.1.5? Reply-to: ian@gamespot.com CC: jkh@time.freebsd.org Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) I saw mention of updates to some of the source and headers for 2.2-current that should provide better SYN flood tolerance. Is there anyway/recipe that you know of to implement these fixes in 2.1.5? I know that DEC and BSDi and others have been publishing patches and kernel reconfigs to "harden" their kernels. One of my machines (ftp.gamespot.com) has been under attack with floods to port 21, the originating IP address is presently filtered at the router but that filter is going to have to come down. Besides, the originator might switch IP addresses soon. Anyway, if you have any suggestions for getting this patched without going to the 2.2 branch, I'd really appreciate it. thanks much in advance -- Ian Kallen ian@gamespot.com Director of Technology & Web Administration http://www.gamespot.com -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-security Fri Nov 8 11:02:33 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA00253 for security-outgoing; Fri, 8 Nov 1996 11:02:33 -0800 (PST) Received: from login.bigblue.no (root@login.bigblue.no [194.19.68.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA00239 for ; Fri, 8 Nov 1996 11:02:26 -0800 (PST) Received: from eagle.bigblue.no (eagle.bigblue.no [194.19.68.13]) by login.bigblue.no (8.7.6/8.7.3) with SMTP id UAA13125 for ; Fri, 8 Nov 1996 20:03:10 +0100 (MET) Message-Id: <199611081903.UAA13125@login.bigblue.no> From: "Frode Nordahl" To: "freebsd-security@freebsd.org" Date: Fri, 08 Nov 96 20:02:02 Reply-To: "Frode Nordahl" Priority: Normal X-Mailer: Frode Nordahl's Registered PMMail 1.53 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: NFS Server, is it secure? Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Starting up an NFS server on a FreeBSD 2.1.5 box, is it secure, given that the configuration is correct? Are there any known holes other than faulty configuration? From owner-freebsd-security Fri Nov 8 12:48:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA07456 for security-outgoing; Fri, 8 Nov 1996 12:48:23 -0800 (PST) Received: from postoffice.cso.uiuc.edu (postoffice.cso.uiuc.edu [128.174.5.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA07446 for ; Fri, 8 Nov 1996 12:48:18 -0800 (PST) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [128.174.83.167]) by postoffice.cso.uiuc.edu (8.6.12/8.6.12) with ESMTP id OAA95844; Fri, 8 Nov 1996 14:48:14 -0600 Received: by alecto.physics.uiuc.edu (940816.SGI.8.6.9/940406.SGI) id OAA10009; Fri, 8 Nov 1996 14:47:54 -0600 From: igor@alecto.physics.uiuc.edu (Igor Roshchin) Message-Id: <199611082047.OAA10009@alecto.physics.uiuc.edu> Subject: Re: NFS Server, is it secure? To: froden@bigblue.no Date: Fri, 8 Nov 1996 14:47:54 -0600 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: <199611081903.UAA13125@login.bigblue.no> from "Frode Nordahl" at Nov 8, 96 08:02:02 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Starting up an NFS server on a FreeBSD 2.1.5 box, is it secure, given that the configuration is correct? Are there any known > holes other than faulty configuration? > > Can anybody show an example how an incorrect configuration of named can decrease security ? From owner-freebsd-security Fri Nov 8 18:21:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA29439 for security-outgoing; Fri, 8 Nov 1996 18:21:59 -0800 (PST) Received: from offensive.communica.com.au (offensive-eth1.adl.communica.com.au [192.82.222.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA29426 for ; Fri, 8 Nov 1996 18:21:46 -0800 (PST) Received: from communica.com.au (frenzy.communica.com.au [192.82.222.65]) by offensive.communica.com.au (8.7.6/8.7.3) with SMTP id MAA06111; Sat, 9 Nov 1996 12:52:50 +1030 (CST) Received: by communica.com.au (4.1/SMI-4.1) id AA12181; Sat, 9 Nov 96 12:50:41 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9611090220.AA12181@communica.com.au> Subject: Re: NFS Server, is it secure? To: froden@bigblue.no Date: Sat, 9 Nov 1996 12:50:41 +1030 (CST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <199611081903.UAA13125@login.bigblue.no> from "Frode Nordahl" at Nov 8, 96 08:02:02 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Frode Nordahl wrote: > Starting up an NFS server on a FreeBSD 2.1.5 box, is it secure, given that > the configuration is correct? Are there any known holes other than > faulty configuration? Well, yes -- NFS is basically never "secure" on any platform. The NFS protocol was never designed with security in mind. If you know (or can guess) the NFS filehandle for an NFS filesystem root then you can spoof the protocol for a start. Firewall your NFS server: Its services should not be reachable from the Internet-at-large. - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au