Bug 478710 - munin-node cannot run smart_ plugin
munin-node cannot run smart_ plugin
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
9
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-03 17:20 EST by Gabriele Pohl
Modified: 2009-06-10 04:12 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-10 04:12:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gabriele Pohl 2009-01-03 17:20:28 EST
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:
Comment 1 Kevin Fenzi 2009-01-04 14:39:45 EST
Adding dwalsh here.
Comment 2 Daniel Walsh 2009-01-05 13:57:31 EST
Miroslav

fstools_domtrans(munin_t) 

Should be added to F9 and F10
Comment 3 Daniel Walsh 2009-01-05 13:58:37 EST
Actually it is already in F10.
Comment 4 Miroslav Grepl 2009-01-14 08:59:03 EST
Fixed in selinux-policy-3.3.1-118.fc9.noarch
Comment 5 Bug Zapper 2009-06-09 23:27:54 EDT
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

Note You need to log in before you can comment on or make changes to this bug.