Subject: Re: i386 IO access and chroot()
To: None <firstname.lastname@example.org>
From: Michael Richardson <email@example.com>
Date: 07/14/2001 21:19:49
>>>>> "Dave" == Dave Sainty <firstname.lastname@example.org> 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[
] email@example.com http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [