Subject: Re: extending chroot()
To: Bill Studenmund <wrstuden@netbsd.org>
From: Steven M. Bellovin <smb@research.att.com>
List: tech-security
Date: 01/17/2003 10:04:35
In message <Pine.NEB.4.33.0301161547001.29370-100000@vespasia.home-net.icnt.net
>, Bill Studenmund writes:
>On Thu, 16 Jan 2003, Steve Bellovin wrote:
>
>> I'd like to be able to "jail" various untrusted applications, such as
>> my netbrowser.  Chroot() is the obvious choice, but it requires root
>> privileges.  However -- supposed we changed chroot() so that it didn't
>> require root, but if executed by a non-root process, setuid and setgid
>> would not be honored.  More precisely, we change the code in
>> exec_script and kern_exec that checks the setuid/setgid bits; if
>> cwdi_rdir is non-null, don't honor those bits.
>
>I think that's a good idea, but I'd rather we not blanket disable
>setuid/setgid bits if root does the chroot. In addition to running
>servers, chroot is good for emulating old versions of the OS. For
>instance, I think a number of folks who run -current compile packages for
>-release in a chroot. It would be nice to have normal setuid/setgid
>semantics there.

Hmm -- I thought the new toolchain was the way to handle that.
>
>Maybe the thing to do is add an "Ignore set-id bits" flag to the process
>state. If you're root, you can chroot and add it (if you like), and if
>you're not root, the flag gets turned on by default. The flag of course
>would be retailed across fork() calls.
>

That's fine.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)