Bug 652074 - SELinux policy causes module loading to fail on read-only root filesystems
Summary: SELinux policy causes module loading to fail on read-only root filesystems
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy
Version: 5.5
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-10 22:51 UTC by Kyle Moffett
Modified: 2013-04-10 07:16 UTC (History)
4 users (show)

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.
Clone Of:
Environment:
Last Closed: 2011-01-13 21:51:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0026 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2011-01-12 16:11:15 UTC

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


Note You need to log in before you can comment on or make changes to this bug.