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).