On Thu, 2008-01-24 at 17:11 +0100, Till Maas wrote: > On Thu January 24 2008, Daniel J Walsh wrote: > > > machine. For example if you are building a Fedora 7 livecd on a Fedora > > 8 host machine, when the new selinux-policy package gets installed the > > Fedora 7 policy will load and replace the Fedora 8 policy. This will > > invalidate any contexts that existed in Fedora 8 and not in Fedora 7 > > causing them to become unlabeled_t. If this happens to a process, the > > process usually goes wild. We (SELinux engineering) is working on some > > solutions, but don't have a good one now. > > > > Virtual machines? Getting the chroot to run with a different kernel. > > Faking out /selinux in chroot to do nothing on policy load? > > Trying to stop Transitions? > > Imho it would be nice if it was possible to mark (label) a directory from the > outside to be the root of the chroot. Then everything within the chroot > directory should have a label for the outside selinux and a label for the > inside selinux. The selinus from the outside should allow everything within > the chroot to to whatever it wants within the chroot (this could be configure > within the policy), but should restrict access to everything outside the > chroot. The selinux within the chroot then should act like there is only the > inside policy and enforce it like it was the only one. I think it would be a property of the chroot'd process and its descendants, not of the directory, as processes operating non-chroot'd may still access the contents of that directory and should still be handled by the host policy. So a per-task policy attribute that would usually always refer to the host/global policy, but could be unshared and then have a private policy loaded for it and its descendants. The main problem is detecting and handling accesses that cross the policy boundary (non-chroot'd process attempts to access file within the directory, chroot'd process manages to break out of the chroot and attempts to access file outside of chroot). -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
