>>>>> "Dave" == Dave Sainty <davedtsp.co.nz> writes:
    Dave> It occurs to me that one could theoretically (but not easily) jump
    Dave> out of a chroot using i386_iopl(2) and related calls, possibly by
    Dave> manipulating the hard drives, possibly some other way.

    Dave> Perhaps these functions (i386_iopl, i386_set_ioperm) should be
    Dave> disabled for chrooted processes?

    Dave> A compile time option to disable them might be a good idea too?
    Dave> (Regardless of what security level you run your kernel at)

  I would agree...

  But, let's do this via "restrict_system()" of some sort, which fixes all
sorts of chroot/security related stuff that we need.

     1. chdir("/") should be included
     2. /dev/zero, /dev/null emulation of some kind. Let's one chroot()
                                to a nodev area.
     3. i386_*() stuff (and whatever there is on other arch's)
     4. bind < 1024
     5. network operations, period

  The whole point is to have a call that root (and optionally non-root)
can call to further restrict stuff.

] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcrsandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
       

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