Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 652074

Summary: SELinux policy causes module loading to fail on read-only root filesystems
Product: Red Hat Enterprise Linux 5 Reporter: Kyle Moffett <Kyle.D.Moffett>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: low    
Version: 5.5CC: dwalsh, ksrot, mmalik, syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-2.4.6-293.el5 Doc Type: Bug Fix
Doc Text:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-13 21:51:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Kyle Moffett 2010-11-10 22:51:36 UTC 
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:

  [sysadm_r:SystemLow-SystemHigh]
  root@alpha:~# udevtrigger && run_init service network restart
  Authenticating sw.
  Password:
  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  ]
  [sysadm_r:SystemLow-SystemHigh]
  root@alpha:~#

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:

type insmod_tmpfs_t;
files_tmpfs_file(insmod_tmpfs_t)
allow insmod_t self:shm create_shm_perms;
manage_files_pattern(insmod_t,insmod_tmpfs_t,insmod_tmpfs_t)
fs_tmpfs_filetrans(insmod_t,insmod_tmpfs_t,file)

I am seeing this problem with the following policy package:
  selinux-policy-mls-2.4.6-279.el5
Comment 1 Daniel Walsh 2010-11-11 14:32:41 UTC 
That looks good to me.
Comment 2 Miroslav Grepl 2010-11-16 14:45:49 UTC 
Fixed in selinux-policy-2.4.6-293.el5.noarch
Comment 6 Jaromir Hradilek 2011-01-05 16:26:45 UTC 
    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.
    
    New Contents:
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.
Comment 8 errata-xmlrpc 2011-01-13 21:51:11 UTC 
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.

http://rhn.redhat.com/errata/RHBA-2011-0026.html