Bug 478710

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: