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.
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.
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
Created attachment 140257 [details] Please apply this policy module to see if if solves your problem semodule -i mdadm.pp
I have added this fix to selinux-policy-2.4.2-7.RHEL5
[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?
I hate when that happens. Check out selinux-policy-2.4.2-7 or later should have the fix.
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?
strict and targeted share the same core policy so yes this would work on all.
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.
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