|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Steven M. Bellovin (smb_at_research.att.com)
Date: Fri Jan 17 2003 - 09:04:35 CST
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)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]