On Fri, 2008-09-12 at 14:35 +0200, Gabriele Pohl wrote: > Hi all, > > my name is Gabriele Pohl. I live in Bonn, Germany > and use Fedora for a few years (starting with > Core 4 and upgraded to 9 some months ago) > > I use Munin (http://munin.projects.linpro.no/) > to monitor my computers hardware and services. > After upgrading to Fedora 9 I decided to use SELinux > in mode *enforce* and run into lots of problems > concerning SELinux and Munin-Plugins, that need > high system privileges to access block devices a.s.o. > > I would like to solve this issues in a good > manner and therefore subscribed to this list > to ask the experts, how to do it. > > Now my first question: > > Plugin smart_ is written in Python. > It calls "smartctl" from the smartmontools package > (http://smartmontools.sourceforge.net/) to read the > values of the SMART-Attributes from the harddisks. > > To activate the plugin, one has to create a link > within the service directory. > > Actually the link looks like this: > lrwxrwxrwx root root unconfined_u:object_r:munin_etc_t:s0 smart_sda > -> /usr/share/munin/plugins/smart_ > > The plugins file looks like this: > -rwxr-xr-x root root > system_u:object_r:munin_exec_t:s0 /usr/share/munin/plugins/smart_ > > Executable smartctl looks like this: > -rwxr-xr-x root root > system_u:object_r:fsadm_exec_t:s0 /usr/sbin/smartctl > > It needs access to the disks block device /dev/sda > that looks like this: > brw-rw---- root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sda > > I have policy type targeted active and > policy module munin 1.4.0 installed. > > 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; > } > 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 ? > > And why are there two identical *require* structs? > Can / Should I delete one of them? > What shall I do with the message of type "SYSCALL" > if it were wrong to put it into the avcs-File? > > 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. The duplicate require blocks look like a bug in audit2allow. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
