OSEC

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

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    In message <Pine.NEB.4.33.0301161547001.29370-100000vespasia.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)