User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.100 Safari/534.30 fail2ban won't start or run properly with selinux on. I get many hundreds of these: type=AVC msg=audit(1309917410.569:2633): avc: denied { write } for pid=23755 comm="fail2ban-client" name="fail2ban.sock" dev=tmpf s ino=58293 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=sock_file type=SYSCALL msg=audit(1309917410.569:2633): arch=c000003e syscall=42 success=no exit=-13 a0=3 a1=7fffb2614210 a2=21 a3=732e6e616232 items=0 ppid=23748 pid=23755 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm ="fail2ban-client" exe="/usr/bin/python" subj=system_u:system_r:initrc_t:s0 key=(null) audit2allow says: allow initrc_t fail2ban_var_run_t:sock_file write; I'm running the latest version I could find mentioned in any of the *many* fail2ban/selinux reports: fail2ban.noarch 0.8.4-27.fc15 @fedora As far as I can tell, this isn't quite the same as any of the other bugs open against fail2ban; my apologies if I missed something. Reproducible: Always Steps to Reproduce: 1. setenforce 1 2. /etc/init.d/fail2ban restart Actual Results: Many hundreds of audit.log lines, fail2ban doesn't log anything, and doesn't seem to actually work. Expected Results: Working fail2ban. As far as I can tell, I've done nothing special on this box *except* disable the unconfined module and set users to staff_u. It is a brand-newly-installed box with almost no packages or configuration. I've therefore set this ticket to "high", because unless fail2ban requires "unconfined" to function, I seem to be seeing that it simply won't work with a base install. Again, my apologies if I missed something.
I take back the comments about unconfined; puppet should have disabled it, but I did an "semodule -R", and I guess that turned it back on?, because I went to test with unconfined enabled and: [root@vrici ~]# semodule -e unconfined libsemanage.semanage_direct_enable: Module unconfined is already enabled.
This is a bug in selinux-policy. The fix for this is in rawhide but needs to be back ported to Fedora 15 (keywords: back port "fail2ban-client" related policy to f15)
Can't get it to set selinux-policy as the component -_-, so just cc'ing dwalsh per dgrift's suggestion. -Robin
Turns out that "yum install selinux-policy --enablerepo=updates-testing" fixes this issue, so I gather it's already on the right track; sorry if I wasted anybody's time. -Robin
Ugh. I'm sorry, that was a lie. I don't know why it worked the one time (perhaps I was in permissive mode), but I still have selinux-policy-3.9.16-32.fc15.noarch installed from rawhide. I have confirmed that with unconfined installed, everything works, and with "semodule -d unconfined", the problem returns, so it's not actually a problem with the base install, only with Dan's blog reccomendation :D, so the severity should be downgraded (which I don't seem to have perms to do). Please let me know if I can help or test this at all. -Robin
Robin, please show me the bug you are seeing with the unconfined module removed? ausearch -m avc -ts recent
It's the same as those mentioned earlier in the ticket; hundreds of these: ---- time->Wed Jul 6 13:15:42 2011 type=SYSCALL msg=audit(1309983342.042:4601): arch=c000003e syscall=42 success=no exit=-13 a0=3 a1=7fff75948b40 a2=21 a3=732e6e616232 items=0 ppid=29501 pid=29508 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python" subj=system_u:system_r:initrc_t:s0 key=(null) type=AVC msg=audit(1309983342.042:4601): avc: denied { write } for pid=29508 comm="fail2ban-client" name="fail2ban.sock" dev=tmpfs ino=83019 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=sock_file ---- time->Wed Jul 6 13:15:43 2011 type=SYSCALL msg=audit(1309983343.048:4611): arch=c000003e syscall=42 success=no exit=-13 a0=3 a1=7fff75948b40 a2=21 a3=732e6e616232 items=0 ppid=29501 pid=29508 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python" subj=system_u:system_r:initrc_t:s0 key=(null) type=AVC msg=audit(1309983343.048:4611): avc: denied { write } for pid=29508 comm="fail2ban-client" name="fail2ban.sock" dev=tmpfs ino=83019 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=sock_file Sorry, you got cc'd half way through; dgrift says this is fixed in rawhide OSLT? (when I said I got the package from rawhide earlier, I meant updates-testing; sorry) -Robin
yes this particular issue should be fixed in rawhide
Back ported Rawhide fail2ban policy selinux-policy-3.9.16-32
Someone please let me know when this is available in updates-testing so I can try it out. Thanks.
Fixed in selinux-policy-3.9.16-33.fc15
selinux-policy-3.9.16-34.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-34.fc15
Package selinux-policy-3.9.16-34.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-34.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-34.fc15 then log in and leave karma (feedback).
Looking good! Thank you. -Robin
selinux-policy-3.9.16-34.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.