Red Hat Bugzilla – Bug 652074
SELinux policy causes module loading to fail on read-only root filesystems
Last modified: 2013-04-10 03:16:34 EDT
Description of problem:
The patch for https://bugzilla.redhat.com/show_bug.cgi?id=430942 did not include a corresponding patch to allow the use of shared memory (by "modprobe") under the SELinux MLS policy.
As a result, our kickstarted RHEL5.5 systems are unable to automatically load modules during the boot process. This is a major regression from our previous baseline configuration on RHEL5.3.
The most obvious symptom of this problem is that none of the network interfaces are started during boot, although once the system is running it can be "fixed" by an administrator (until the next reboot). Sample shell transcript is below:
root@alpha:~# udevtrigger && run_init service network restart
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface netA: [ OK ]
Bringing up interface netB: [ OK ]
Bringing up interface netC: [ OK ]
Bringing up interface owtS: [ OK ]
Bringing up interface owtU: [ OK ]
Bringing up interface peer: [ OK ]
As far as I can tell, a "standard" install using LVM or similar is unaffected by this bug, probably because the root filesystem is initially mounted read/write or the modules are loaded by the initramfs (or similar).
By adding the following lines to the modutils.te policy source file and rebuilding the policy package, we were able to resolve the problem:
allow insmod_t self:shm create_shm_perms;
I am seeing this problem with the following policy package:
That looks good to me.
Fixed in selinux-policy-2.4.6-293.el5.noarch
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Under certain circumstances, a system may have been unable to automatically load certain modules at a boot time. When this happened, network interfaces may not have been started during the boot, and had to be started manually. With this update, several rules have been added to the SELinux MLS (Multilevel Security) policy to allow the use of shared memory, resolving this issue.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.