>>>>> "Dave" == Dave Sainty <dave@dtsp.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[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [