Bug 213669 - Targeted policy does not allow mdadm to create files in /dev
Targeted policy does not allow mdadm to create files in /dev
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
bzcl34nup
:
Depends On:
Blocks: 213671
  Show dependency treegraph
 
Reported: 2006-11-02 09:33 EST by Doug Ledford
Modified: 2008-05-07 05:47 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:59:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Please apply this policy module to see if if solves your problem (21.04 KB, application/octet-stream)
2006-11-03 10:40 EST, Daniel Walsh
no flags Details

  None (edit)
Description Doug Ledford 2006-11-02 09:33:08 EST
Description of problem:

The mdadm program has, for a long time, been able to automatically create
entries in /dev when starting an array that does not already have a device file
created in /dev.  This has to be done because in order to start the array, you
need to open that array's device file to tell the kernel what devices to add to
the array.  Since /dev is not prepopulated with all possible /dev/md? entries,
mdadm creates those that it needs.  However, with targeted policy, that is
prevented and array startup is halted.

Version-Release number of selected component (if applicable):

Fedora Core 6 and rawhide, mdadm 2.5.4

How reproducible:

100%

Steps to Reproduce:
1. Install system with a /boot software raid array
2. Boot into rescue mode and recreate array with a version 1 superblock
3. While in rescue mode, change /etc/rc.d/rc.sysinit to call mdadm -A -s
--auto=yes when attempting to start arrays (in the if [ -f /etc/mdadm.conf ] block)
4. Boot in selinux enforcing mode, see avc denied and system fails to boot properly
5. Boot in permissive mode and see mdadm succeed in starting array.
  
Actual results:
System fails to boot properly and falls into repair mode.

Expected results:
Should boot up.

Additional info:

This problem has existed all along, but has been hidden by the kernel's autorun
feature.  In rc.sysinit, just prior to calling mdadm to start arrays, we use
nash to signal an autorun attempt to the kernel.  The kernel will only recognize
the older 0.90 version superblocks when doing autorun.  If you opt to use the
later version 1.0 superblock instead, autorun fails.  At that point, it's up to
mdadm to start the arrays.  That's when this becomes a problem.  However, during
the next rawhide cycle, I intend to get anaconda and mkinitrd and initscripts
all updated to start arrays using mdadm, not autorun, so that anaconda can use
some of the advanced features of the 1.0 superblocks when creating new arrays. 
This issue will hold that work up.
Comment 1 Daniel Walsh 2006-11-03 10:07:54 EST
Please include avc messages from boot in permissive mode.  Also I believe these
devices will be created with the wrong context on them, so your script will
probably have to run restorecon on it.  Or does mdadm always create the same
type of devices, in which case I can write policy to transition mdadm created
devices to the correct context.  
Comment 2 Doug Ledford 2006-11-03 10:29:36 EST
mdadm is a utility for managing md software raid device.  It only creates device
files for md block devices (it does, however, access other block device files
when assembling md devices, eg. it may access /dev/sda1 and /dev/sdb1 to
assemble /dev/md0).  The files created by mdadm should basically always be
treated as though it were a SCSI or IDE hard disc.

Here's the avc messages:

audit(1162485489.567:3): avc:  denied  { write } for  pid=1199 comm="mdadm"
name="/" dev=tmpfs ino=679 scontext=system_u:system_r:mdadm_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=dir
audit(1162485489.567:4): avc:  denied  { mknod } for  pid=1199 comm="mdadm"
capability=27 scontext=system_u:system_r:mdadm_t:s0
tcontext=system_u:system_r:mdadm_t:s0 tclass=capability
audit(1162485489.567:5): avc:  denied  { add_name } for  pid=1199 comm="mdadm"
name="md1" scontext=system_u:system_r:mdadm_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=dir
audit(1162485489.567:6): avc:  denied  { create } for  pid=1199 comm="mdadm"
name="md1" scontext=system_u:system_r:mdadm_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=blk_file
audit(1162485489.567:7): avc:  denied  { setattr } for  pid=1199 comm="mdadm"
name="md1" dev=tmpfs ino=5154 scontext=system_u:system_r:mdadm_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=blk_file
audit(1162485489.567:8): avc:  denied  { read write } for  pid=1199 comm="mdadm"
name="md1" dev=tmpfs ino=5154 scontext=system_u:system_r:mdadm_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=blk_file
Comment 3 Daniel Walsh 2006-11-03 10:40:12 EST
Created attachment 140257 [details]
Please apply this policy module to see if if solves your problem

semodule -i mdadm.pp
Comment 4 Daniel Walsh 2006-11-03 10:41:54 EST
I have added this fix to selinux-policy-2.4.2-7.RHEL5
Comment 5 Doug Ledford 2006-11-03 14:15:11 EST
[root@firewall ~]# semodule -i ~dledford/mdadm.pp 
libsepol.permission_copy_callback: Module mdadm depends on permission
setsockcreate in class process, not satisfied
libsemanage.semanage_link_sandbox: Link packages failed
semodule:  Failed!
[root@firewall ~]# 



I have no idea what the above means, but I'm guessing it didn't install the
policy and that means I can't test it :-/

This is a FC6 box.  Could I just install the selinux-policy for RHEL5 or do they
diverge significantly?
Comment 6 Daniel Walsh 2006-11-03 16:28:53 EST
I hate when that happens.  Check out selinux-policy-2.4.2-7 or later should have
the fix.

Comment 7 Doug Ledford 2006-11-03 18:24:07 EST
OK, in permissive mode I no longer get any denied messages.  I'll try enforcing
a little later, but I assume it will work.  This is with targeted setting, what
about strict?  Should it work too?
Comment 8 Daniel Walsh 2006-11-06 10:32:40 EST
strict and targeted share the same core policy so yes this would work on all.
Comment 9 Bug Zapper 2008-04-03 14:34:58 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 10 Bug Zapper 2008-05-06 20:59:03 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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