Bug 428942

# audit2allow -M mypol -i /var/log/audit/audit.log 
# semodule -i mypol.pp

Fixed in selinux-policy-3.0.8-78.fc8

Created attachment 291896 [details]
te from my audit log

thanks for the help.  here's a longer list from audit2allow
:-)

i'm not sure when all those permissions were required - possibly during an
initialisation script run when it was installed?  they make a kind of sense
though - munin-node does need to be able to check/examine lots of subsystems.

the audit messages i initially reported are what comes up when i start the
munin-node service now.  i can't get the long list of denials to happen again
even if i run munin-node-configure.

aha - i've finally figured out where those extra denials came from.  i
temporarily did a "setenforce 0" and let munin-node run a few times.

so that should be the complete list.

i've been adding those allows gradually just to make sure i know what's causing
each.  semodule has got stuck on the next one for hddtemp/smartctl:

# grep allow mypol28.te
allow munin_t fixed_disk_device_t:blk_file { read write };
# semodule -i mypol28.pp
libsepol.check_assertion_helper: neverallow violated by allow munin_t
fixed_disk_device_t:blk_file { write }; Cannot allocate memory.
libsemanage.semanage_expand_sandbox: Expand module failed Cannot allocate memory.
semodule:  Failed!

Yes you probably do not want to do this.  Since this would bypass SELinux
controls and allow munin to read/write any file on any disk.

fsadm_domtrans(munin_t) 

Would be better.

I am building most of your fixes into 
selinux-policy-3.0.8-79.fc8

hello again,

i've got selinux-policy-3.0.8-84.fc8 and munin-node=1.2.5-4.fc8 now.  here's the
latest allows from audit2allow when running munin (well, munin-node) with
setenforce 0:

#comm=munin-node
allow munin_t munin_port_t:tcp_socket name_bind;
#comm=open_files
allow munin_t sysctl_fs_t:dir search;
allow munin_t sysctl_fs_t:file read;
#comm=df
allow munin_t mnt_t:dir search;
allow munin_t var_lib_nfs_t:dir search;

Looks like this is fixed in selinux-policy-3.0.8-87.fc8

confirmed.  i removed my local policy and restarted munin-node and all seems to
be well.

big thanks!

:-)

I have clean install of F8 and when starting munin-node I get AVC:

type=AVC msg=audit(1205745740.545:2323): avc:  denied  { name_bind } for 
pid=27366 comm="munin-node" src=4949 scontext=unconfined_u:system_r:munin_t:s0
tcontext=system_u:object_r:munin_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1205745740.545:2323): arch=40000003 syscall=102
success=no exit=-13 a0=2 a1=bfb95540 a2=4c15cc a3=10 items=0 ppid=1 pid=27366
auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
comm="munin-node" exe="/usr/bin/perl" subj=unconfined_u:system_r:munin_t:s0
key=(null)

System is fully updated with selinux-policy-3.0.8-87.fc8

This does not seem to me as being fixed. munin-node is still not able to connect
to socket.

hmm.  yeah, i'm getting that now too, and a bunch of other denials when i
setenforce off.

confused.

i had thought that it was messed up because of the remnants of my local policy.
  then i thought it needed a relabel.  i was going to have a look in koji next
to see if the last lot of changes had got over-written.

i think at my comment #9 i should have rebooted before declaring it working. 
apologies for that.  i'm afraid i'm still a beginner when it comes to
understanding and testing selinux.

You can allow this for now by executing 

# audit2allow -M mypol -i /var/log/audit/audit.log 
# semodule -i mypol.pp

Fixed in selinux-policy-3.0.8-94.fc8

hello, thanks for the very quick responses.  sorry this is dragging on.

the "bunch of other denials" i mentioned in comment #11 produce the following
".te" from audit2allow:

allow munin_t mqueue_spool_t:dir read;
allow munin_t munin_port_t:tcp_socket name_bind;
allow munin_t mysqld_etc_t:file { read getattr };
allow munin_t postfix_spool_maildrop_t:dir read;
allow munin_t postfix_spool_t:dir read;
allow munin_t sysctl_fs_t:file read;
allow munin_t sysctl_irq_t:dir getattr;
allow munin_t sysctl_rpc_t:dir search;
allow munin_t sysctl_rpc_t:file { read getattr };
allow munin_t var_spool_t:dir read;

all of those apart from the munin_port_t one were in my original attachment.  is
it possible my current policy has got confused because i did:
1) add local policies
2) update system policy through selinux-policy packages
3) remove local policies

might step 3) have removed some policies which were added in 1) but included in 2)?

since then i'm pretty sure i've had another selinux-policy package update and
i've done a full relabel and reboot but i still get those denials.  any ideas?

*** Bug 438825 has been marked as a duplicate of this bug. ***

Please attach the audit.log  I believe this should have been fixed in the 94/95
policy and munin should be transitioning to the system_mail domain.  Which would
handle all of those avc's.  So please update to policy 95 and then try the munin
code out and if you see avc's please attach them.

I updated to updates-testing -95 version. Restarting munin-node service generates:
type=AVC msg=audit(1206708224.880:20297): avc:  denied  { name_bind } for 
pid=8482 comm="munin-node" src=4949 scontext=unconfine
d_u:system_r:munin_t:s0 tcontext=system_u:object_r:munin_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1206708224.880:20297): arch=40000003 syscall=102
success=no exit=-13 a0=2 a1=bfb18840 a2=4c15cc a3=10 item
s=0 ppid=1 pid=8482 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) comm="munin-node" exe="/usr/bin/p
erl" subj=unconfined_u:system_r:munin_t:s0 key=(null)

This is pretty the same one..
If I have to do something else (relabel something?), then let me know.

If you run this through audit2why what does it say?

# audit2why < munin.avc
type=AVC msg=audit(1206716914.876:20531): avc:  denied  { name_bind } for 
pid=9038 comm="munin-node" src=4949 scontext=unconfined_u:system_r:munin_t:s0
tcontext=system_u:object_r:munin_port_t:s0 tclass=tcp_socket
        Was caused by:
                Missing or disabled TE allow rule.
                Allow rules may exist but be disabled by boolean settings; check
boolean settings.
                You can see the necessary allow rules by running audit2allow
with this audit message as input.

# audit2allow < munin.avc

#============= munin_t ==============
allow munin_t munin_port_t:tcp_socket name_bind;

Ok, I built /selinux-policy-3.0.8-96.fc8 and audit2why says it has this fix.  I
will putting this out in Fedora-Testing today.

I don't understand why it was not in 95, since the fix should have been there.

So far, there is no such update available, therefore I downloaded the -97 from
koji, but I still see the same AVC message. I feel pretty stupid to say that,
but I am not very experienced with selinux, to verify this rule is in this update.

Ah.. I see now where the confusion comes from. I selectively updated
selinux-policy, but it does not have as a dependency the
selinux-policy-targeted. :( The munin-node is running now with
selinux-policy-targeted-3.0.8-97.fc8.noarch.rpm.

Daniel, the munin-node is now running. But some of the servicies it provides are
still blocked by SELinux. E.g.
type=AVC msg=audit(1207420504.598:6727): avc:  denied  { getattr } for 
pid=23146 comm="ping_" path="/bin/ping" dev=dm-0 ino=33751
scontext=unconfined_u:system_r:munin_t:s0 tcontext=system_u:object_r:ping_exe
c_t:s0 tclass=file
type=SYSCALL msg=audit(1207420504.598:6727): arch=40000003 syscall=195
success=no exit=-13 a0=92cff48 a1=bfbb9e30 a2=8a0ff4 a3=92cff48 items=0
ppid=23142 pid=23146 auid=500 uid=99 gid=484 euid=99 suid=99 fsui
d=99 egid=484 sgid=484 fsgid=484 tty=(none) comm="ping_" exe="/bin/bash"
subj=unconfined_u:system_r:munin_t:s0 key=(null)

How to proceed with that? Filling a bug for each plugin is not probably very
wise. Should we fill them all to this bug - some were already meantioned by cje?
Wouldn't it be better for you to start this service yourself - it seems this
package is completely unhandled by SELinux.

Could you give me a list of what the services need to be able to do.

I am not that experienced to say that. Fedora includes munin-node package - this
is statistical collecting engine. This package contains 121 plugins to collect
information about various system activities or network health. You can list them
under /usr/share/munin/plugins. Those are usually shell scripts or perl scripts
returning values that are stored in rrd a they access various resources to
collect these data. It's beyond may capabilities to provide all selinux rules.
Is it possible to have some very general rule for munin and his plugins?

hi guys!  just thought i'd have a look and see what the problem was ... and it
turns out it's pretty much working :-)

(i had thought it was still broken because i was getting selinux denial
notifications every time the plugins ran but it turns out that's just a couple
of problems with probably just one plugin.)

looking at my munin graphs i can see that everything sprang back into life on
Apr 21.  presumably that's when i did a reboot after installing 3.0.8-95 on Apr 4.

so, many thanks Dan!

what's left?  well, i've still got the following (from audit2allow)

# src="munin_t" tgt="mqueue_spool_t" class="dir", perms="read"
# comm="find" exe="" path=""
allow munin_t mqueue_spool_t:dir read;
# src="munin_t" tgt="postfix_spool_maildrop_t" class="dir", perms="read"
# comm="find" exe="" path=""
allow munin_t postfix_spool_maildrop_t:dir read;
# src="munin_t" tgt="postfix_spool_t" class="dir", perms="read"
# comm="find" exe="" path=""
allow munin_t postfix_spool_t:dir read;

but i'm not sure what that's actually doing as i do get valid-looking postfix
stats.  i'll check up on that.

Adam, i don't get any message similar to the ping-related ones you list in
comment 22.  could you say what plugins you're using so i can try to reproduce
those messages?  the output of the following should be what we need:

munin-node-configure | grep yes

:-)

weirdly, since the Apr 21 return munin is reporting less than ten processes in
the "number of processes" graph.  before it was a more accurate 200 or more.

also the hddtemp stuff never recovered but i'm looking into that.

okay.  the hddtemp stuff is back.  a munin-node update had (i think) commented
out the definition of the list of drives.

still got the other errors.  low number of processes might be explained by the
long list of permission denied messages appearing in munin-node.log like this:

find: /proc/1: Permission denied

the plugin script does this:

find /proc -maxdepth 1 -name '[1-9]*' -print | wc -l | sed 's/\t +//' | sed 's/ *//'

which works fine (returns 245 at the moment) when run as root or a regular user.

2cje: those are just another munin plugins like ping_ you can find it in 
/usr/share/munin/plugins/.

ah yes, i should have guessed.  ;-)

i get some similar errors now but one confused me so i thought i'd check the
context of the plugin executables - and they're all a bit mixed up.  restorecon
has no effect so i guess there's no rule for the contexts of the symlinks in
/etc/munin/plugins.

i've set all mine to system_u:object_r:munin_exec_t with:

chcon system_u:object_r:munin_exec_t /etc/munin/plugins/*

Daniel, can we add a file rule in the policy to get those symlinks set to that
context?  they're links to the plugin executables in /usr/share/munin/plugins
which _does_ have such a rule.  (the symlinks have names which are the main
argument for the plugin.  e.g. there's the "ping_" plugin file and you can make
a symlink "ping_www.redhat.com" to get it to ping redhat.)

anyway, that should sort out the AVC message you're getting - which will allow
munin-node to run the ping_ script .. which will then fail.  here's the extra
requirements from audit2allow for the ping plugin:

#============= ping_t ==============
# src="ping_t" tgt="munin_log_t" class="file", perms="append"
# comm="ping" exe="" path=""
allow ping_t munin_log_t:file append;
# src="ping_t" tgt="munin_t" class="tcp_socket", perms="{ read write }"
# comm="ping" exe="" path=""
allow ping_t munin_t:tcp_socket { read write };

which sounds plausible to me.

This looks like a leaked file descriptor in munin

allow ping_t munin_t:tcp_socket { read write };

I will fix the append to log file

How should the policy rules for the processes plugin be fixed?  It currently runs:

$ find /proc -noleaf -maxdepth 1 -name '[1-9]*' -print | wc -l | sed 's/\t +//' | sed 's/ *//'

The associated AVC's generate the following audit2allow rules on my system:

============= munin_t ==============
allow munin_t audisp_t:dir getattr;
allow munin_t auditd_t:dir getattr;
allow munin_t crond_t:dir getattr;
allow munin_t dhcpd_t:dir getattr;
allow munin_t getty_t:dir getattr;
allow munin_t init_t:dir getattr;
allow munin_t kernel_t:dir getattr;
allow munin_t ntpd_t:dir getattr;
allow munin_t restorecond_t:dir getattr;
allow munin_t security_t:dir search;
allow munin_t selinux_config_t:dir search;
allow munin_t sendmail_t:dir getattr;
allow munin_t sshd_t:dir getattr;
allow munin_t syslogd_t:dir getattr;
allow munin_t udev_t:dir getattr;
allow munin_t unconfined_t:dir getattr;

The problem is this isn't a complete list.  Seems you'd need to add all known types, or some kind of wildcard rule if that was supported?

domain_read_all_domains_state(munin_t) would do what you want.

thank you. that worked great.  could we get that added to the munin policy?

selinux-policy-3.0.8-122.fc8 has this dontaudited check it out to see if it works properly for you

Sorry, I should have said I'm on F9, which is how I ran into this problem. 

selinux-policy-3.3.1-99.fc9 doesn't allow the processes plugin to work unless I use domain_read_all_domains_state(munin_t).  I get a whole bunch of permission denies as shown in comment #27.  If this was fixed in F8, it wasn't carried over to F9 (or something else is going on).

Fixed in selinux-policy-3.3.1-105.fc9

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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

There are still some problems remaining with munin in F9, moving to F9.

Please attach the avc messages for F9

Created attachment 325103 [details]
complete audit.log for munin AVCs

Attached is audit.log with all the AVCs related to munin. I'd like to point to fact that I do not have all the munin plugins enabled. They are located under /usr/share/munin/plugins.

Are you seeing another AVCs, when you are handling with munin ?

Thanks

Just what I have in a syslog now:

Jan  9 11:45:07 server setroubleshoot: SELinux is preventing df (munin_t) "search" to ./mnt (mnt_t). For complete SELinux messages.
run sealert -l 949054ed-7e44-4312-8b7c-0ca976235ac9
Jan  9 11:45:09 server setroubleshoot: SELinux is preventing df (munin_t) "search" to ./nfs (var_lib_nfs_t). For complete SELinux me
ssages. run sealert -l 1a250108-4029-4ebf-b343-4fe0973302e1
Jan  9 11:45:10 server setroubleshoot: SELinux is preventing postfix_mailque (munin_t) "getattr" to /var/spool/postfix (postfix_spoo
l_t). For complete SELinux messages. run sealert -l 698c9ac8-8e71-4a70-bba8-c10aca43a450
Jan  9 11:45:12 server setroubleshoot: SELinux is preventing df (munin_t) "search" to ./mnt (mnt_t). For complete SELinux messages.
run sealert -l 949054ed-7e44-4312-8b7c-0ca976235ac9
Jan  9 11:45:13 server setroubleshoot: SELinux is preventing df (munin_t) "search" to ./nfs (var_lib_nfs_t). For complete SELinux me
ssages. run sealert -l 1a250108-4029-4ebf-b343-4fe0973302e1
Jan  9 11:45:15 server setroubleshoot: SELinux is preventing ping (ping_t) "read write" munin_t. For complete SELinux messages. run
sealert -l d2fec2b2-04a8-4329-a5f6-b43d2d0a401e
Jan  9 11:45:16 server setroubleshoot: SELinux is preventing df (munin_t) "search" to ./mnt (mnt_t). For complete SELinux messages.
run sealert -l 949054ed-7e44-4312-8b7c-0ca976235ac9
Jan  9 11:45:18 server setroubleshoot: SELinux is preventing df (munin_t) "search" to ./nfs (var_lib_nfs_t). For complete SELinux me
ssages. run sealert -l 1a250108-4029-4ebf-b343-4fe0973302e1
Jan  9 11:45:19 server setroubleshoot: SELinux is preventing postfix_mailvol (munin_t) "getattr" to /var/log/maillog (var_log_t). Fo
r complete SELinux messages. run sealert -l 13c2651f-3088-47c7-b35f-36e1db6144ea
Jan  9 11:45:20 server setroubleshoot: SELinux is preventing ping (ping_t) "read write" munin_t. For complete SELinux messages. run
sealert -l d2fec2b2-04a8-4329-a5f6-b43d2d0a401e

Fixed in selinux-policy-3.3.1-118.fc9.noarch

sorry i've taken so long to have another look at this.

i've switched on as many plugins as i can right now (which is by no means all but does include nfs, postfix, ping and filesystem) in F10 (selinux-policy-3.5.13-45.fc10.noarch) and can't generate any selinux denials.

so i'm happy to close this.

Adam, how's it looking on F9?

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