Description of problem: Although I configured root access executing the smart_ plugin in munin-node.. [smart_*] user root ..SELinux blocks the access to device. I wrote to the SELinux-Support list a while ago: http://www.redhat.com/archives/fedora-selinux-list/2008-September/msg00073.html ------------- snip ------------- > I get the following raw audit messages, when > calling smart_sda: > > host=calex.dipohl.com type=AVC msg=audit(1221221404.542:709): avc: > denied { getattr } for pid=18327 comm="python" path="/dev/sda" dev=tmpfs > ino=298 scontext=unconfined_u:system_r:munin_t:s0 > tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file > > host=calex.dipohl.com type=SYSCALL msg=audit(1221221404.542:709): > arch=40000003 syscall=195 success=no exit=-13 a0=8fbe278 a1=bfcdf038 > a2=3e8ff4 a3=8f481b8 items=0 ppid=18220 pid=18327 auid=500 uid=0 gid=491 > euid=0 suid=0 fsuid=0 egid=491 sgid=491 fsgid=491 tty=(none) ses=1 > comm="python" exe="/usr/bin/python" > subj=unconfined_u:system_r:munin_t:s0 key=(null) > > As the FAQ said, I fed these messages into audit2allow: > audit2allow -M mine < avcs > > and get the following mine.te: > ------------------------------- > module mine 1.0; > > require { > type munin_t; > type fixed_disk_device_t; > class blk_file getattr; > } > > #============= munin_t ============== > allow munin_t fixed_disk_device_t:blk_file getattr; > ------------------------------- > > and a mine.pp > > Will it be ok to load that into the kernel using > semodule -i mine.pp ? > > Should I make adjustments to the files above > (service-link, plugin-file) > > Anything else, that you can advise? Ideally the munin_t domain itself shouldn't need any access to the raw device - it should transition into the existing domain for smartd (fsdaemon_t) upon executing the smartctl program. I don't know offhand if the existing munin policy module has such a domain transition rule. However, mere getattr access (i.e. the ability to stat the file) isn't a big deal, so you could likely grant that one w/o difficulty. What would be more problematic is allowing read or write access to the raw device. -- Stephen Smalley National Security Agency ------------- snip ------------- I hope you can improve the current munin-node policies so, that it use "transition into the existing domain for smartd (fsdaemon_t) upon executing the smartctl program", as Stephen advises. Version-Release number of selected component (if applicable): - selinux-policy-targeted-3.3.1-116.fc9.noarch - munin-node-1.2.6-3.fc9.noarch How reproducible: Activate plugin smart_ Steps to Reproduce: 1. Create link in service directory e.g. /etc/munin/plugins/smart_sda 2. Grant root access in /etc/munin/plugin-conf.d/munin-node 3. Restart munin-node Actual results: Messages in /var/log/munin-node.log 2009/01/03-20:05:03 Plugin "smart_sda" exited with status 256. ---- 2009/01/03-20:05:04 Plugin "smart_sdb" exited with status 256. ---- 2009/01/03-20:05:05 Plugin "smart_sda" exited with status 256. ---- 2009/01/03-20:05:09 Plugin "smart_sdb" exited with status 256. ---- No data fetched. NaN values stored in RRD. Expected results: smart_c collecting data. This works after adding the following additional rules: ================= snip ==================== module smart 1.0; require { type munin_t; type fixed_disk_device_t; class blk_file getattr; } require { type munin_t; type fixed_disk_device_t; class blk_file getattr; } #============= munin_t ============== allow munin_t fixed_disk_device_t:blk_file getattr; Additional info:
Adding dwalsh here.
Miroslav fstools_domtrans(munin_t) Should be added to F9 and F10
Actually it is already in F10.
Fixed in selinux-policy-3.3.1-118.fc9.noarch
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping