Subject: Re: extending chroot()
To: Bill Studenmund <>
From: Steven M. Bellovin <>
List: tech-security
Date: 01/17/2003 10:04:35
In message <
>, 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, (me) (2nd edition of "Firewalls" book)