Red Hat Bugzilla – Bug 391451
SELinux: Chroot Install/Update with Enforcing Mode
Last modified: 2009-01-08 13:30:20 EST
LTSP needs to install a Fedora chroot into a location like /opt/ltsp/i386 for
thin clients to boot over a network.
LTSP could use various tools like anaconda, mock or yum directly to install this
chroot. The latest code uses anaconda due to the convenience of kickstart
definitions to install this chroot, but we could use any tool.
Unfortunately, chroot install with anaconda fails because various operations
during RPM are denied while SELinux is enforcing. It appears that depmod,
ldconfig and more are denied. Reportedly mock does something to avoid SELinux
denials but I don't understand it at the moment.
We need a solution to allow us to keep SELinux enabled during:
1) Install without SELinux denials.
2) yum operation within the chroot without SELinux denials.
For the purpose of LTSP we don't use SELinux enabled on the booted thin clients,
so proper labeling is not important within the chroot. We don't care if the
contents within the chroot are properly labeled or not as a result. However
future users of netbooted workstations will want full SELinux protection and
proper labeling within the chroot.
1) Is there anything that can be done in selinux-policy to allow install and yum
update within the chroot without AVC denials?
2) Is it possible to do this while maintaining proper labels within the chroot?
Talked a bit with dwalsh about this last week.
anaconda with --noselinux will install a chroot unlabeled, which installs and
internally yum updates just fine. This will suit the needs for LTSP initially.
Supporting SELinux enabled netboot workstations later however will require far
more difficult changes to how SELinux works.
Which executable do you use to create this environment?
anaconda without --noselinux will label the contents inside, causing things to
explode during installation if enforcing (broken chroot). You need to set it to
permissive to install with labeling. That is a problem.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Changes are rolling into Fedora 9 to allow livecd to create a system in
enforcing mode. These changes should help with this problem.
the -26 kernel is required