| Summary: | fail2ban selinux problems which seem different from other reported bugs | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Robin Powell <rlpowell> |
| Component: | selinux-policy | Assignee: | Axel Thimm <axel.thimm> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | axel.thimm, dominick.grift, dwalsh, jonathan.underwood, mgrepl |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-3.9.16-34.fc15 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-07-18 22:32:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
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. |
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.