Bug 428942 - munin won't run with selinux enabled ... again.
munin won't run with selinux enabled ... again.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
: Reopened
: 438825 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-16 02:50 EST by cje
Modified: 2009-06-10 04:26 EDT (History)
4 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-10 04:26:45 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)
te from my audit log (12.13 KB, application/octet-stream)
2008-01-16 16:30 EST, cje
no flags Details
complete audit.log for munin AVCs (66.00 KB, application/x-gzip)
2008-11-29 15:19 EST, Adam Pribyl
no flags Details

  None (edit)
Description cje 2008-01-16 02:50:37 EST
got some more avc denials so i guess we need another munin module update?

type=AVC msg=audit(1200467402.989:22296): avc:  denied  { write } for  pid=17040
comm="munin-node" path="pipe:[825166]" dev=pipefs ino=825166
scontext=unconfined_u:system_r:munin_t:s0
tcontext=unconfined_u:system_r:munin_t:s0 tclass=fifo_file
type=AVC msg=audit(1200467702.824:22315): avc:  denied  { ioctl } for  pid=17153
comm="munin-node" path="pipe:[825582]" dev=pipefs ino=825582
scontext=unconfined_u:system_r:munin_t:s0
tcontext=unconfined_u:system_r:munin_t:s0 tclass=fifo_file
type=AVC msg=audit(1200467702.824:22316): avc:  denied  { read } for  pid=17153
comm="munin-node" path="pipe:[825582]" dev=pipefs ino=825582
scontext=unconfined_u:system_r:munin_t:s0
tcontext=unconfined_u:system_r:munin_t:s0 tclass=fifo_file
type=AVC msg=audit(1200467702.825:22317): avc:  denied  { execute_no_trans } for
 pid=17154 comm="munin-node"
path="/usr/share/munin/plugins/sendmail_mailtraffic" dev=dm-0 ino=294389921
scontext=unconfined_u:system_r:munin_t:s0
tcontext=system_u:object_r:munin_exec_t:s0 tclass=file
type=AVC msg=audit(1200467903.391:22321): avc:  denied  { dac_override } for 
pid=24221 comm="munin-node" capability=1
scontext=unconfined_u:system_r:munin_t:s0
tcontext=unconfined_u:system_r:munin_t:s0 tclass=capability
type=AVC msg=audit(1200467904.206:22322): avc:  denied  { search } for 
pid=17250 comm="munin-node" name="munin" dev=dm-0 ino=218529796
scontext=unconfined_u:system_r:munin_t:s0
tcontext=system_u:object_r:munin_log_t:s0 tclass=dir

the 'search' one is stopping munin-node from starting as it claims it's getting
permission denied on the log file.  i think it needs search permission on dirs
with munin_log_t.

looks like we need read, write, ioctl for munin_t fifo_file.  i can't see any
policy for fifo_file in the module at the moment.

not sure about the dac_override and execute_no_trans.  are these booleans
i/munin-node should be setting?

as you may be able to tell - i'm not an selinux person.  i just looked in the
logs and in seaudit.

:-)
Comment 1 Daniel Walsh 2008-01-16 16:15:35 EST
# audit2allow -M mypol -i /var/log/audit/audit.log 
# semodule -i mypol.pp

Fixed in selinux-policy-3.0.8-78.fc8
Comment 2 cje 2008-01-16 16:30:08 EST
Created attachment 291896 [details]
te from my audit log

thanks for the help.  here's a longer list from audit2allow
:-)
Comment 3 cje 2008-01-16 16:46:33 EST
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.
Comment 4 cje 2008-01-16 17:48:12 EST
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.
Comment 5 cje 2008-01-16 19:09:50 EST
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!

Comment 6 Daniel Walsh 2008-01-17 13:52:16 EST
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
Comment 7 cje 2008-02-24 08:58:39 EST
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;
Comment 8 Daniel Walsh 2008-02-26 09:41:24 EST
Looks like this is fixed in selinux-policy-3.0.8-87.fc8
Comment 9 cje 2008-03-03 20:25:52 EST
confirmed.  i removed my local policy and restarted munin-node and all seems to
be well.

big thanks!

:-)
Comment 10 Adam Pribyl 2008-03-17 05:36:34 EDT
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.
Comment 11 cje 2008-03-17 05:52:31 EDT
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.
Comment 12 Daniel Walsh 2008-03-17 08:46:32 EDT
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
Comment 13 cje 2008-03-17 11:11:26 EDT
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?
Comment 14 Kevin Fenzi 2008-03-25 11:47:59 EDT
*** Bug 438825 has been marked as a duplicate of this bug. ***
Comment 15 Daniel Walsh 2008-03-28 06:39:38 EDT
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.

Comment 16 Adam Pribyl 2008-03-28 08:54:52 EDT
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.
Comment 17 Daniel Walsh 2008-03-28 09:23:50 EDT
If you run this through audit2why what does it say?
Comment 18 Adam Pribyl 2008-03-28 11:11:55 EDT
# 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;
Comment 19 Daniel Walsh 2008-03-29 07:06:45 EDT
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.
Comment 20 Adam Pribyl 2008-04-01 09:43:34 EDT
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.
Comment 21 Adam Pribyl 2008-04-01 09:56:58 EDT
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.
Comment 22 Adam Pribyl 2008-04-06 04:04:23 EDT
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.
Comment 23 Daniel Walsh 2008-04-06 05:34:02 EDT
Could you give me a list of what the services need to be able to do.

Comment 24 Adam Pribyl 2008-04-08 14:48:27 EDT
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?
Comment 25 cje 2008-05-31 21:57:31 EDT
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

:-)
Comment 26 cje 2008-05-31 22:07:29 EDT
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.
Comment 27 cje 2008-05-31 22:27:53 EDT
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.
Comment 28 Adam Pribyl 2008-06-01 13:28:39 EDT
2cje: those are just another munin plugins like ping_ you can find it in 
/usr/share/munin/plugins/.
Comment 29 cje 2008-06-01 15:02:22 EDT
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.
Comment 30 Daniel Walsh 2008-06-02 13:44:34 EDT
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
Comment 31 Zing 2008-10-24 15:51:48 EDT
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?
Comment 32 Daniel Walsh 2008-10-27 17:02:48 EDT
domain_read_all_domains_state(munin_t) would do what you want.
Comment 33 Zing 2008-10-27 22:31:15 EDT
thank you. that worked great.  could we get that added to the munin policy?
Comment 34 Daniel Walsh 2008-10-28 19:48:42 EDT
selinux-policy-3.0.8-122.fc8 has this dontaudited check it out to see if it works properly for you
Comment 35 Zing 2008-10-28 21:49:25 EDT
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).
Comment 36 Daniel Walsh 2008-10-29 09:50:28 EDT
Fixed in selinux-policy-3.3.1-105.fc9
Comment 37 Bug Zapper 2008-11-26 04:27:15 EST
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
Comment 38 Adam Pribyl 2008-11-26 05:14:46 EST
There are still some problems remaining with munin in F9, moving to F9.
Comment 39 Daniel Walsh 2008-11-27 07:12:54 EST
Please attach the avc messages for F9
Comment 40 Adam Pribyl 2008-11-29 15:19:10 EST
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.
Comment 41 Miroslav Grepl 2009-01-08 09:48:23 EST
Are you seeing another AVCs, when you are handling with munin ?

Thanks
Comment 42 Adam Pribyl 2009-01-09 06:27:40 EST
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
Comment 43 Miroslav Grepl 2009-01-14 08:59:43 EST
Fixed in selinux-policy-3.3.1-118.fc9.noarch
Comment 44 cje 2009-03-02 20:59:48 EST
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?
Comment 45 Bug Zapper 2009-06-09 19:23:01 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.