Red Hat Bugzilla – Bug 156767
targeted policy mishandles chroot
Last modified: 2007-11-30 17:11:05 EST
The current selinux targeted policy mishandles chroot environments. This is
demonstrated by the fact that selinux must be disabled in order to set up a xen
The problem is that selinux uses inadequately qualified paths. The module should
be exporting paths relative to absolute root, not just paths relative to current
chroot. These should then be matched in the policy using some sort of macro-ized
regular expression, as in:
$(ROOTS)/usr/bin ....... what to do .....
where $ROOT is a variable of some sort giving the RE that matches all of the
global absolute paths of all valid chroot environments.
In order to enforce this (i.e. avoid inadvertent error), the policy for the
chroot system call should involve a second variable that defaults as
and chroot() should fail unless the provided absolute path is in fact a known
chroot environment listed in $(CHROOTS). This will ensure that people update the
ROOTS variable correctly when they create jails, or update the CHROOTS variable
if it really is there intention NOT to enforce within a particular chroot
The key point is that the absence of control in this regard is a real nuisance,
and the inability to set up a subsystem like xen without disabling selinux is
ipso facto an indication of selinux having a design flaw (and prone to causing
lots of issues -- see my other bug about recovering from updates done when
selinux was disabled).
I think the core of the problem here is that we've always been abusing chroot()
as a weak virtualization mechanism. People often want to install different OS
releases into separate chroots, but the problem is that chroot only virtualizes
some of the filesystem space. It does not virtualize e.g. the TCP socket space,
nor, crucially, the kernel (in this case, /proc).
What is happening here is that libselinux inside your chroot is determining that
SELinux is enabled in your kernel by looking at /proc.
The solution is to use Xen instead of chroot. Now, we currently have the issue
that in order to install a Xen guest, you need to use a host-based chroot
environment. However, work is progressing to do the install fully in the guest,
and once that work is complete, this problem is solved.
Even ignoring the weak virtualization issue in chroot (and I agree with what you
say), one of the points of chroot is to set up sub-environments that have
different restrictions than the "real" system. If the selinux rules do not
operate on the real path, it becomes very difficult to modify policies based on
which chroot environment they are in.
Offtopic for this bug, but I'ld appreciate amplification from Colin about the
interaction between /proc and selinux. If I understand correctly what is
happening, the xen install fails because the native-crossmounted /proc indicates
that selinux is running?
So if that's the case, I infer that in a conventional bare-machine install, the
kernel that loads of the CD does *not* run selinux and therefore the interaction
between libselinux and /proc does not arise? Or perhaps it runs selinux in
It would be very nice if this were the case, because then I can see some ways to
trick the current xen setup into working without disabling selinux. Since it's
pretty clear that guest-native install isn't going to make the release date
cutoff, that seems like a useful thing to be able to do.
There is an undocumented feature in setfiles -r that allows you to relabel your
setfiles -r /mychroot /etc/selinux/targeted/contexts/files/file_context /mychroot
Ok Looking back on this looks like an RPM bug. I am attempting this here.
With SELinux, you really no longer need chroot for access control. SELinux
allows you to very flexibly specify which domains are allowed what kind of
access to which files.
As for /proc; yes, it's the crossmount that indicates to the software inside the
chroot that it's running. I don't know about what Anaconda does. Perhaps it
does run in permissive mode.
If the guest-native install won't make the release date, we might be able to add
a hack which will make doing e.g FC4 guest install on a FC4 system work (since
the policy is the same).
Philosphically, it's not appropriate to say "selinux trumps chroot". Even if
this is true (which it is not), there are a large number of apps that must run
on other platforms too, where chroot is the only available option. Concerns of
compatibility and reduced engineering cost will dictate the use of chroot for
In regard to guest-native install, I have no information to suggest that this
will be ready in time for FC4 freeze. However, Dan Walsh and I have been working
to get a revision to Jeremy's currently recommended install assembled. He has
just sent me a script that he think works, and I'm about to cross check him.
Assuming that works, I think it would be okay to downgrade this bug from
security to normal.
Suggest we leave it be for the moment, and I'll get back to you later tonight to
report on whether I have confirmed Dan's changes.
I have confirmed that Dan's script changes for xen-guest install work correctly.
There is a remaining unrelated bug in the libgcc postinstall script, but that
has nothing to do with this bug.
While we have solved the xen-guest problem (and much thanks to Dan), I still
don't feel that the concern I was trying to raise has been addressed. On the
other hand, I don't think that I expressed it very well at all, and I need to do
some homework to get a more refined statement of the issue together. I can't see
that any purpose is served by keeping this bug open until then, so I'm going to
go ahead and close it.