From owner-freebsd-security Sun Feb 23 00:00:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA27412 for security-outgoing; Sun, 23 Feb 1997 00:00:42 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27377; Sun, 23 Feb 1997 00:00:06 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id SAA09960; Sun, 23 Feb 1997 18:54:23 +1100 (EST) From: Julian Assange Message-Id: <199702230754.SAA09960@profane.iq.org> Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments In-Reply-To: <27770.856542186@critter.dk.tfs.com> from Poul-Henning Kamp at "Feb 21, 97 05:23:06 pm" To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Sun, 23 Feb 1997 18:54:22 +1100 (EST) Cc: security@freebsd.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (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 > >: >I have read it twice now, to be quite honest, this sort of change scares > >: >the hell out of me. It seems like it'd be real easy to make a mondo > >: >security hole out of it due to the usual chroot() risks. No, it has the same protection that LD_PRELOAD does. > >I took a quick peek at it while looking for other security problems, > > Considering the way shared libs work, I would not trust a program in > a chroot sandbox to use the shlibs I use outside. This does >not< > in any way improve security. The only way to break out of the sandbox into the shlib image is if the vm system is broken and permits mprotect() transition to PROT_WRITE/MAP_SHARED of the shlib code area, which was opened as RDONLY and mapped PROT_READ/MAP_COPY. mmap.2 -> [EACCES] The flag PROT_READ was specified as part of the prot param- eter and fd was not open for reading. The flags PROT_WRITE, MAP_SHARED and MAP_WRITE were specified as part of the flags and prot parameters and fd was not open for writing. I haven't tested to see if the vm system is broken. If it is it must be fixed. Dyson? > Complication (and slowing down) the shlib startup is not warranted > by the gain in functionality. Did you actually look at the patch? It only requires an additional getenv (not a system call). There are several in ld.so. L("LD_LIBRARY_PATH=", 1, &ld_library_path) L("LD_PRELOAD=", 1, &ld_preload) L("LD_IGNORE_MISSING_OBJECTS=", 1, &ld_ignore_missing_objects) L("LD_TRACE_LOADED_OBJECTS=", 0, &ld_tracing) L("LD_BIND_NOW=", 0, &ld_bind_now) L("LD_SUPPRESS_WARNINGS=", 0, &ld_suppress_warnings) L("LD_WARN_NON_PURE_CODE=", 0, &ld_warn_non_pure_code) > You can obtain the same savings in disk by hardlinking the copies of > the shlibs together (since they're probably on the same filesystem anyway. Oh boy. > I vote >NO< to this change. Maybe you should read your signature first ;) > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. > Power and ignorance is a disgusting cocktail. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-security Sun Feb 23 00:16:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA27931 for security-outgoing; Sun, 23 Feb 1997 00:16:08 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27891; Sun, 23 Feb 1997 00:15:49 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id TAA10018; Sun, 23 Feb 1997 19:10:20 +1100 (EST) From: Julian Assange Message-Id: <199702230810.TAA10018@profane.iq.org> Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments In-Reply-To: <199702210853.QAA15189@spinner.DIALix.COM> from Peter Wemm at "Feb 21, 97 04:53:33 pm" To: peter@spinner.DIALix.COM (Peter Wemm) Date: Sun, 23 Feb 1997 19:10:20 +1100 (EST) Cc: hackers@freebsd.org, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (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 > What's to stop a user from setting LD_CHROOT to a "hostile" invironment, > running a setuid program (which ignores LD_CHROOT), which happens to set > it's uid's to the new id, and that process exec's some binary with uid == > euid now, so that new binary now takes note of LD_CHROOT and is now > vulnerable to the "hostile" chroot environment... Same argument applies to all the LD_* variables. This technique was used to undermine the sync:: account under sunos with login -p etc > Also, wouldn't this be better in crt0.c so it'd be usable for statically > linked binaries? crt0.c should be as minimal as possible (since it is linked with all code) , and the crt0.c solution requires relinking of all binaries (which may not be possible). Further, statics don't have as much need for this type of thing. > Hmm.. another thing.. Once the chroot has happened, nothing removes the > LD_CHROOT variable from the environment.. Any sub processes will also try > to chroot within the chroot space.. This chould be a bit noisy.. :-] You shouldn't be running sub-processes in the chroot space that are dynamically linked, because they won't be able to get at the shlibs or ld.so. None-the-less it is probably worthwhile zorching LD_CHROOT when chroot() is called. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-security Sun Feb 23 04:18:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA07400 for security-outgoing; Sun, 23 Feb 1997 04:18:09 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA07394; Sun, 23 Feb 1997 04:18:02 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id NAA16739; Sun, 23 Feb 1997 13:17:43 +0100 (MET) From: Guido van Rooij Message-Id: <199702231217.NAA16739@gvr.win.tue.nl> Subject: Re: improved setuid and device file checker for /etc/security In-Reply-To: <199702230636.WAA22830@salsa.gv.tsc.tdk.com> from Don Lewis at "Feb 22, 97 10:36:27 pm" To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Sun, 23 Feb 1997 13:17:42 +0100 (MET) Cc: freebsd-isp@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (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 Don Lewis wrote: > A few weeks ago I solicited input on how to prevent locate.updatedb and > /etc/security wasting a lot of time digging around the article spool on > our news server. I got a lot of suggestions on different ways to tweak > these scripts to prevent this, but the suggestions mostly involved making > custom changes to these scripts that would be somewhat of a hassle to > maintain. The locate stuff is easy. You can specify parts that have to be skipped. If I remember corectly, it can be controlled by locate.conf in /etc. But only in 2.2. -Guido From owner-freebsd-security Sun Feb 23 05:55:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA10624 for security-outgoing; Sun, 23 Feb 1997 05:55:08 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA10619; Sun, 23 Feb 1997 05:55:05 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id OAA02292; Sun, 23 Feb 1997 14:53:00 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.8.5/8.7.2) with SMTP id OAA11550; Sun, 23 Feb 1997 14:49:02 +0100 (MET) Message-Id: <3.0.32.19970223144902.00c19100@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 23 Feb 1997 14:49:03 +0100 To: Julian Assange From: Eivind Eklund Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments Cc: peter@spinner.DIALix.COM (Peter Wemm), hackers@freebsd.org, security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 07:10 PM 2/23/97 +1100, Julian Assange wrote: >> What's to stop a user from setting LD_CHROOT to a "hostile" invironment, >> running a setuid program (which ignores LD_CHROOT), which happens to set >> it's uid's to the new id, and that process exec's some binary with uid == >> euid now, so that new binary now takes note of LD_CHROOT and is now >> vulnerable to the "hostile" chroot environment... > >Same argument applies to all the LD_* variables. This technique was used >to undermine the sync:: account under sunos with login -p etc Not quite. If we allow users to do this to setuid binaries, they can make setuid programs read dangerous config files, and exploit the new behaviour. A really simple example would be to create a fake /etc with a new master.passwd and run su. Sure, you have su only in the chroot()ed environment, but you could easily create a new suid binary... There is a reason chroot() is restricted to root, and I think we'd better keep that. If the patch was changed to restrict use to non-suid only (ie, root only), I'd be much more comfortable with it. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-security Sun Feb 23 06:21:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA11828 for security-outgoing; Sun, 23 Feb 1997 06:21:21 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA11822; Sun, 23 Feb 1997 06:21:14 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id BAA10178; Mon, 24 Feb 1997 01:16:47 +1100 (EST) From: Julian Assange Message-Id: <199702231416.BAA10178@profane.iq.org> Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments In-Reply-To: <3.0.32.19970223144902.00c19100@dimaga.com> from Eivind Eklund at "Feb 23, 97 02:49:03 pm" To: eivind@dimaga.com (Eivind Eklund) Date: Mon, 24 Feb 1997 01:16:47 +1100 (EST) Cc: hackers@freebsd.org, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (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 > Not quite. If we allow users to do this to setuid binaries, they can make > setuid programs read dangerous config files, and exploit the new behaviour. > A really simple example would be to create a fake /etc with a new > master.passwd and run su. Sure, you have su only in the chroot()ed > environment, but you could easily create a new suid binary... > > There is a reason chroot() is restricted to root, and I think we'd better > keep that. If the patch was changed to restrict use to non-suid only (ie, > root only), I'd be much more comfortable with it. It is restricted to non-suid, just the same as LD_PRELOAD is. There is an "unsafe" field in the scan_tab for all enviromental variables used by ld.so. It's set to on for LD_CHROOT. You may want to have a look at this before presuming I'm a complete fool ;) -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-security Sun Feb 23 06:54:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA13824 for security-outgoing; Sun, 23 Feb 1997 06:54:49 -0800 (PST) Received: from bofh.cybercity.dk (bofh.cybercity.dk [195.8.128.254]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA13777; Sun, 23 Feb 1997 06:54:41 -0800 (PST) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.133.247]) by bofh.cybercity.dk (8.8.3/8.7.3) with ESMTP id PAA06885; Sun, 23 Feb 1997 15:56:54 +0100 (MET) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id PAA02532; Sun, 23 Feb 1997 15:57:23 +0100 (MET) To: Julian Assange cc: eivind@dimaga.com (Eivind Eklund), hackers@freebsd.org, security@freebsd.org Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments In-reply-to: Your message of "Mon, 24 Feb 1997 01:16:47 +1100." <199702231416.BAA10178@profane.iq.org> Date: Sun, 23 Feb 1997 15:57:22 +0100 Message-ID: <2530.856709842@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702231416.BAA10178@profane.iq.org>, Julian Assange writes: >> Not quite. If we allow users to do this to setuid binaries, they can make >> setuid programs read dangerous config files, and exploit the new behaviour. >> A really simple example would be to create a fake /etc with a new >> master.passwd and run su. Sure, you have su only in the chroot()ed >> environment, but you could easily create a new suid binary... >> >> There is a reason chroot() is restricted to root, and I think we'd better >> keep that. If the patch was changed to restrict use to non-suid only (ie, >> root only), I'd be much more comfortable with it. > >It is restricted to non-suid, just the same as LD_PRELOAD is. There >is an "unsafe" field in the scan_tab for all enviromental variables >used by ld.so. It's set to on for LD_CHROOT. You may want to have >a look at this before presuming I'm a complete fool ;) Listen, this patch is maybe or maybe not correct, but it certainly is pointless. For anything as little used as chroot to clobber the one of the most timecritical piece of code in userland is simply not an option, in particular where there isn't any better argumentation that "it would be neat of one could..." Can this discussion please be taken offline now ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-security Mon Feb 24 00:45:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA08853 for security-outgoing; Mon, 24 Feb 1997 00:45:50 -0800 (PST) Received: from mailserv.tversu.ac.ru (mailserv.tversu.ac.ru [193.233.128.3]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA08848 for ; Mon, 24 Feb 1997 00:45:36 -0800 (PST) Received: (from vadim@localhost) by mailserv.tversu.ac.ru (8.6.12/8.6.12) id LAA19757; Mon, 24 Feb 1997 11:45:55 +0300 Message-ID: <19970224114554.12677@mailserv.tversu.ac.ru> Date: Mon, 24 Feb 1997 11:45:54 +0300 From: Vadim Kolontsov To: freebsd-security@FreeBSD.Org Subject: Re: improved setuid and device file checker for /etc/security References: <199702230636.WAA22830@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199702230636.WAA22830@salsa.gv.tsc.tdk.com>; from Don Lewis on Feb 02, 1997 at 10:36:27PM -0800 Sender: owner-security@FreeBSD.Org X-Loop: FreeBSD.org Precedence: bulk On Feb 02, 1997 at 10:36:27PM -0800, Don Lewis wrote: > At least in the case of /etc/security, I came up with a scheme that should > be a lot more automatic. > I also added device file checking (other than their timestamps which tend > do get updated). Here is my contribution to /etc/security... It works fine on my machine. I've added more convinient (I hope :) scheme to check (and backup) some important files. Also checking for users's .rhosts added ---------------------------- cut here ------------------------------------ BAK=/var/backups CHECKFILES="aliases master.passwd group aliases security hosts.equiv" echo "" echo "Backuping and checking some files:" for i in $CHECKFILES ; do if cmp -s $BAK/$i /etc/$i; then echo " * $i"; else echo " * /etc/$i diffs:" echo ---------------------------------------------------------- diff $BAK/$i /etc/$i echo ---------------------------------------------------------- mv $BAK/$i $BAK/$i.bak cp -p /etc/$i $BAK fi done echo "" echo "Looking for user's .rhosts" for pwdentry in `awk 'BEGIN { FS=":" } {printf $1"@"$6" "}' /etc/passwd`; do user=`echo $pwdentry | sed "s/@.*//g"` homedir=`echo $pwdentry | sed "s/.*@//g"` if [ -e $homedir/.rhosts ] ; then if cmp -s $BAK/rhosts/$user $homedir/.rhosts ; then echo " * $user"; else echo " * $user's .rhosts diffs:" echo ---------------------------------------------------------- diff $BAK/rhosts/$user $homedir/.rhosts echo ---------------------------------------------------------- mv $BAK/rhosts/$user $BAK/rhosts/$user.bak cp -p $homedir/.rhosts $BAK/rhosts/$user fi fi done ---------------------------- cut here ------------------------------------ -------------------------------------------------------------------------- Vadim Kolontsov SysAdm/Programmer Tver Regional Center of New Information Technologies Networks Lab From owner-freebsd-security Mon Feb 24 05:37:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA19373 for security-outgoing; Mon, 24 Feb 1997 05:37:11 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA19358; Mon, 24 Feb 1997 05:36:36 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id AAA10815; Tue, 25 Feb 1997 00:28:34 +1100 (EST) From: Julian Assange Message-Id: <199702241328.AAA10815@profane.iq.org> Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments In-Reply-To: <2530.856709842@critter.dk.tfs.com> from Poul-Henning Kamp at "Feb 23, 97 03:57:22 pm" To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Tue, 25 Feb 1997 00:28:33 +1100 (EST) Cc: hackers@freebsd.org, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (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 > >It is restricted to non-suid, just the same as LD_PRELOAD is. There > >is an "unsafe" field in the scan_tab for all enviromental variables > >used by ld.so. It's set to on for LD_CHROOT. You may want to have > >a look at this before presuming I'm a complete fool ;) > > Listen, this patch is maybe or maybe not correct, but it certainly > is pointless. > > For anything as little used as chroot to clobber the one of the most > timecritical piece of code in userland is simply not an option, in > particular where there isn't any better argumentation that "it would > be neat of one could..." > > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. Have you actually ever looked at rtld.c? Alone it over 53k long. It is full of debug code that is normally never used. A p-100 class machine does around 173,000 getenv("LD_CHROOT")'s a second. What plannet are you on? The primary reason chroot() is rarely used is because it is painful to use. LD_CHROOT makes it very, very easy to use. That said, I have absolutely no doubt chroot() is used more than LD_LIBRARY_PATH, LD_PRELOAD, LD_IGNORE_MISSING_OBJECTS, LD_TRACE_LOADED_OBJECTS, LD_BIND_NOW, LD_SUPPRESS_WARNINGS and LD_WARN_NON_PURE_CODE put together. It would be neat if one could actually use the chroot() facility in a secure and efficient manner, without modifying the source for main() on every binary in the system. You are right. It would be neat. Since when is something being small, fast, secure, neat and providing functionality that wouldn't otherwise be there grounds for rejection of code? I'm quite apalled at this conservative view, expressed without the slightest understanding of the code involved. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-security Mon Feb 24 08:02:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA25622 for security-outgoing; Mon, 24 Feb 1997 08:02:51 -0800 (PST) Received: from bofh.cybercity.dk (bofh.cybercity.dk [195.8.128.254]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA25592; Mon, 24 Feb 1997 08:02:42 -0800 (PST) Received: from critter.dk.tfs.com ([140.145.230.252]) by bofh.cybercity.dk (8.8.3/8.7.3) with ESMTP id RAA26167; Mon, 24 Feb 1997 17:04:49 +0100 (MET) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id RAA04365; Mon, 24 Feb 1997 17:05:00 +0100 (MET) To: Julian Assange cc: hackers@freebsd.org, security@freebsd.org Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments In-reply-to: Your message of "Tue, 25 Feb 1997 00:28:33 +1100." <199702241328.AAA10815@profane.iq.org> Date: Mon, 24 Feb 1997 17:05:00 +0100 Message-ID: <4363.856800300@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702241328.AAA10815@profane.iq.org>, Julian Assange writes: >plannet are you on? Earth, 3rd from the center. (Mostly harmless). >The primary reason chroot() is rarely used is because it is painful >to use. No, it's because it doesn't really offer isolation when you have networking and other non-filesystem controlled interfaces to the kernel. Once you have implemented true "virtual machine" semantics for chroot, including local /sbin/init process &c &c it will be useful. >I'm quite apalled at this conservative view, >expressed without the slightest understanding of the code involved. I have a far better understanding of the code than you have. Julian, you need to calm down and work on something different. Your proposed feature isn't the magical bullet it takes to make chroot a safe place to live. If it were I would embrace it. As it is, adding this gruesome hack doesn't really provide us with anything that improves the situation. If you think otherwise, do it on your own systems. Poul-Henning -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-security Mon Feb 24 09:32:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA02659 for security-outgoing; Mon, 24 Feb 1997 09:32:31 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA02653; Mon, 24 Feb 1997 09:32:23 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA24627; Mon, 24 Feb 1997 10:28:40 -0700 From: Terry Lambert Message-Id: <199702241728.KAA24627@phaeton.artisoft.com> Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments To: proff@iq.org (Julian Assange) Date: Mon, 24 Feb 1997 10:28:40 -0700 (MST) Cc: phk@critter.dk.tfs.com, hackers@freebsd.org, security@freebsd.org In-Reply-To: <199702241328.AAA10815@profane.iq.org> from "Julian Assange" at Feb 25, 97 00:28:33 am X-Mailer: ELM [version 2.4 PL24] 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 > The primary reason chroot() is rarely used is because it is painful > to use. LD_CHROOT makes it very, very easy to use. That said, I > have absolutely no doubt chroot() is used more than LD_LIBRARY_PATH, > LD_PRELOAD, LD_IGNORE_MISSING_OBJECTS, LD_TRACE_LOADED_OBJECTS, > LD_BIND_NOW, LD_SUPPRESS_WARNINGS and LD_WARN_NON_PURE_CODE put > together. The chroot/shared library interaction is the only painful element in using chroot(). This should be "fixed" with a loopback mount, rather than by the granting of a path lookup exception. In general, the use of a NULL chroot vp in a proc struct to indicate a non-chroot'ed process to namei(), is a bad thing. This special case code should go (and if it did, so would LD_CHROOT's utility). This would leave each process running on its own root vnode, effectively, and by default that vnode would be the real root. To resolve the mount covering FS geometry change update problem (which is *NOT* resolved in the chroot case currently, and is kludge-resolved in the non-chrooted process by reevaluation of the root vnode in the case of a NULL chroot vnode), you would need to use a vnode pointer pointer for the chroot vnode, and an addref/release mechanism for the pointer pointer reference to the pointer so that a placeholder vnode that wasn't a mount point could be freed when its last reference went away. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-security Mon Feb 24 11:25:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA10010 for security-outgoing; Mon, 24 Feb 1997 11:25:48 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA10004; Mon, 24 Feb 1997 11:25:40 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id UAA03721; Mon, 24 Feb 1997 20:24:42 +0100 (MET) From: Guido van Rooij Message-Id: <199702241924.UAA03721@gvr.win.tue.nl> Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments In-Reply-To: <199702241328.AAA10815@profane.iq.org> from Julian Assange at "Feb 25, 97 00:28:33 am" To: proff@iq.org (Julian Assange) Date: Mon, 24 Feb 1997 20:24:42 +0100 (MET) Cc: phk@critter.dk.tfs.com, hackers@freebsd.org, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (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 > > It would be neat if one could actually use the chroot() facility > in a secure and efficient manner, without modifying the source for > main() on every binary in the system. You are right. It would be > neat. Since when is something being small, fast, secure, neat and > providing functionality that wouldn't otherwise be there grounds > for rejection of code? I'm quite apalled at this conservative view, > expressed without the slightest understanding of the code involved. > I understand your point and partly I do agree. However, seeing the enormous security hole we found lately in having the setlocale() stuff in ld.so, ppl are a bit reluctant to modify such a piece of code. I think that is understandable. What I do when I want a chroot jail is use a simple program, chrootuid, that does almost the same. In my opinion, that is a cleaner solution because whenever something would be broken, it is only this tiny little program that is broken, instead of *all* binaries. The fact that your code is probably correct does not change this fact. Btw: chroouit can be found at ftp.win.tue.nl:/pub/security -Guido From owner-freebsd-security Wed Feb 26 10:19:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA23110 for security-outgoing; Wed, 26 Feb 1997 10:19:03 -0800 (PST) Received: from scruz.net (nic.scruz.net [165.227.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA23100 for ; Wed, 26 Feb 1997 10:18:59 -0800 (PST) Received: (from simon@localhost) by scruz.net (8.7.3/1.34) id KAA20073; Wed, 26 Feb 1997 10:18:54 -0800 (PST) Date: Wed, 26 Feb 1997 10:18:54 -0800 (PST) From: admin@scruz.net (Simon) Message-Id: <199702261818.KAA20073@scruz.net> X-Authentication-Warning: nic.scruz.net: simon set sender to admin@scruz.net using -f To: security@freebsd.org Subject: [SCZ-34647] Patch for SYN flooding Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, We're an ISP in Santa Cruz, California that runs FreeBSD on some of our servers. We occaisonally experience unintentional SYN flooding attacks due to uni-directional routing or similar problems. We understand that there is a patch available that adresses the SYN flooding problem. We would like to get information about this patch, what it does, are where we can find it. We'd appreciate any information you can give us. Thanks, Simon scruznet network operations ----------------------------------------------------------------------------- Scruz-Net, Inc. * (800) 319-5555 * (408) 457-5050 * FAX: (408) 457-1020 admin@scruz.net From owner-freebsd-security Wed Feb 26 11:18:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA26694 for security-outgoing; Wed, 26 Feb 1997 11:18:30 -0800 (PST) Received: from kithrup.com (kithrup.com [205.179.156.40]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA26689 for ; Wed, 26 Feb 1997 11:18:29 -0800 (PST) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id LAA14593; Wed, 26 Feb 1997 11:18:26 -0800 Date: Wed, 26 Feb 1997 11:18:26 -0800 From: Sean Eric Fagan Message-Id: <199702261918.LAA14593@kithrup.com> To: simon@scruz.net Subject: Re: [SCZ-34647] Patch for SYN flooding Newsgroups: kithrup.freebsd.security In-Reply-To: <199702261818.KAA20073.kithrup.freebsd.security@scruz.net> Organization: Kithrup Enterprises, Ltd. Cc: security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199702261818.KAA20073.kithrup.freebsd.security@scruz.net> you write: >We >would like to get information about this patch, what it does, >are where we can find it. Unless you like getting automated responses, do not send any mail to admin@scruz.net. Despite many requests by me to not send an automated response to anything with a Subject: Re:, they have not done so. Sending an address like that out to a mailing list is particularly rude and clueless. Sean. From owner-freebsd-security Wed Feb 26 11:32:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA27572 for security-outgoing; Wed, 26 Feb 1997 11:32:25 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA27563 for ; Wed, 26 Feb 1997 11:32:15 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id MAA11886; Wed, 26 Feb 1997 12:32:05 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id MAA01387; Wed, 26 Feb 1997 12:31:50 -0700 (MST) Date: Wed, 26 Feb 1997 12:31:49 -0700 (MST) From: Marc Slemko To: Simon cc: security@FreeBSD.ORG Subject: Re: [SCZ-34647] Patch for SYN flooding In-Reply-To: <199702261818.KAA20073@scruz.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 If you run 2.1-stable or 2.2 it is already there. I think it was in 2.1.6 (err... the second 2.1.6 I think), and it is in 2.1.7. If you run 2.1.x, keeping up to date with the -stable tree is always good. There are few modifications to that tree, but important things like security fixes are made there a lot of the time. It implements oldest early drop, so that when the queue fills up it drops the oldest uncompleted connection. I think it makes a half-hearted attempt at random early drop when the rate gets very high, but that is horribly inefficient and will remain that way until that queue is moved into a hash table from a linked list. Works reasonably well, although you may want to bump up somaxconn and the backlog param in the listen() call of your server depending on your situation. On Wed, 26 Feb 1997, Simon wrote: > Hi, > > We're an ISP in Santa Cruz, California that runs FreeBSD on some of our > servers. We occaisonally experience unintentional SYN flooding attacks > due to uni-directional routing or similar problems. We understand that > there is a patch available that adresses the SYN flooding problem. We > would like to get information about this patch, what it does, > are where we can find it. We'd appreciate any information you can give > us. > > Thanks, > Simon > scruznet network operations > > ----------------------------------------------------------------------------- > Scruz-Net, Inc. * (800) 319-5555 * (408) 457-5050 * FAX: (408) 457-1020 > admin@scruz.net > From owner-freebsd-security Sat Mar 1 04:48:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA03540 for security-outgoing; Sat, 1 Mar 1997 04:48:52 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA03531 for ; Sat, 1 Mar 1997 04:48:44 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id NAA18698; Sat, 1 Mar 1997 13:48:34 +0100 (MET) From: Guido van Rooij Message-Id: <199703011248.NAA18698@gvr.win.tue.nl> Subject: Re: 2.1.7 requires a rebuild of /usr/local binaries? In-Reply-To: <199702211734.KAA03840@elara.frii.com> from "gnat@frii.com" at "Feb 21, 97 10:34:25 am" To: gnat@frii.com Date: Sat, 1 Mar 1997 13:48:34 +0100 (MET) Cc: freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (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 gnat@frii.com wrote: > I've just installed 2.1.7 (upgrading from 2.1.5) on my own machine, > prior to upgrading all our servers. The advisory re: the setlocale > bug said to rebuild all statically linked binaries and probably all > dynamically linked ones too. > > Going to the 2.1.7-RELEASE/packages directory, however, I see it's > just a link to the 2.1.6 packages directory. Does this mean that I > don't have to rebuild all my binaries after all? Indeed. A scan through all ports revealed apparently no suid binaries taht are statically linked. The only problems would arise with these kind of binaries. -Guido