Bug 156767

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
permissive mode?

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

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

Colin:

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
these applications.

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.

Dan, all:

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.