Bug 213669
| Summary: | Targeted policy does not allow mdadm to create files in /dev | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Doug Ledford <dledford> | ||||
| Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | CC: | triage | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | bzcl34nup | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-05-07 00:59:05 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: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 213671 | ||||||
| Attachments: |
|
||||||
|
Description
Doug Ledford
2006-11-02 14:33:08 UTC
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 |