On Tuesday 22 February 2005 00:54, Alexandre Oliva <aoliva@xxxxxxxxxx> wrote: > On Feb 19, 2005, Russell Coker <russell@xxxxxxxxxxxx> wrote: > > SE Linux controls all aspects of system security, including global > > thing such as mounting file systems and directly writing to block > > devices. If the chroot had a local policy as you suggest then which > > policy would control writing to the device node for the boot device? > > Err... No differently from the way the Xen solution you recommended > would? Except, perhaps, for... Xen is totally different to a chroot. Xen has a virtual environment which has it's own access controls. The URL below concerns methods of limiting interaction between Xen sessions (I don't know enough about Xen to comment on it). With a chroot you might have /dev/hda1 mounted as the root file system, but inside the chroot the /dev/hda1 device node will still exist and grant access to the file system that's outside the chroot. I believe that Xen solves this problem but don't know the details. > > http://sourceforge.net/mailarchive/forum.php?thread_id=6364737&forum_id=3 > >5600 > > which would require presumably yet another layer of MAC configuration > files. Which means yet another level of setting up and overlapping > settings, not really different from one possible implementation for > chroot policies. True, it could be considered to be slightly similar in concept to a well implemented chroot setup. But note that a Xen guest can't change the resources managed by the Xen host, and a similar level of isolation is required for a secure chroot. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
