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