Description of problem: I get the following AVC denials in enforcing mode when restarting fail2ban. It seems to work okay, but perhaps it is causing some issues. Testing with fail2ban-0.8.7.1 that I'm looking to put into epel testing soon. type=AVC msg=audit(1349981935.471:201175): avc: denied { read } for pid=8000 comm="sendmail" path="inotify" dev=inotifyfs ino=1 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir type=AVC msg=audit(1349981937.843:201177): avc: denied { read write } for pid=8014 comm="iptables" path=2F746D702F6666696A6247646764202864656C6574656429 dev=tmpfs ino=11662541 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:object_r:fail2ban_tmp_t:s0 tclass=file type=AVC msg=audit(1349981944.846:201189): avc: denied { execute } for pid=8069 comm="sh" name="ldconfig" dev=dm-0 ino=45391 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file type=AVC msg=audit(1349981944.847:201190): avc: denied { getattr } for pid=8069 comm="sh" path="/sbin/ldconfig" dev=dm-0 ino=45391 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file type=AVC msg=audit(1349981946.196:201192): avc: denied { read } for pid=8077 comm="iptables" path="/var/log/messages" dev=dm-2 ino=3547 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file I suppose most of these are leaked file descriptors. fail2ban does set FD_CLOEXEC in a couple places, but maybe not all. It's the inotify one that is strange to me. There is an old Bug 478690 that mentions those and claims they were fixed back in the Fedora 10 days, so I'm surprised to see them here. Version-Release number of selected component (if applicable): selinux-policy-3.7.19-155.el6_3.4.noarch fail2ban-0.8.7.1-1.el6.noarch
Looks like fail2ban is leaking a open file descriptor to inotify type=AVC msg=audit(1349981935.471:201175): avc: denied { read } for pid=8000 comm="sendmail" path="inotify" dev=inotifyfs ino=1 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir And to /var/log/messages, I guarantee iptables is not reading it. The other AVC's are allowed in Fedora.
# rpm -qa | grep -e selinux-policy -e fail2ban | sort fail2ban-0.8.4-28.el6.noarch selinux-policy-3.7.19-169.el6.noarch selinux-policy-targeted-3.7.19-169.el6.noarch # sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 24 Policy from config file: targeted # ---- type=SYSCALL msg=audit(10/12/2012 11:42:45.190:29) : arch=x86_64 syscall=execve success=no exit=-13(Permission denied) a0=1975890 a1=1974970 a2=1975c40 a3=7fff8d649330 items=0 ppid=2301 pid=2302 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1 comm=sh exe=/bin/bash subj=unconfined_u:system_r:fail2ban_t:s0 key=(null) type=AVC msg=audit(10/12/2012 11:42:45.190:29) : avc: denied { execute } for pid=2302 comm=sh name=ldconfig dev=sda3 ino=4849899 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- type=SYSCALL msg=audit(10/12/2012 11:42:45.190:30) : arch=x86_64 syscall=stat success=no exit=-13(Permission denied) a0=1975890 a1=7fff8d649510 a2=7fff8d649510 a3=7fff8d649330 items=0 ppid=2301 pid=2302 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1 comm=sh exe=/bin/bash subj=unconfined_u:system_r:fail2ban_t:s0 key=(null) type=AVC msg=audit(10/12/2012 11:42:45.190:30) : avc: denied { getattr } for pid=2302 comm=sh path=/sbin/ldconfig dev=sda3 ino=4849899 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- type=SYSCALL msg=audit(10/12/2012 11:42:45.288:32) : arch=x86_64 syscall=socket success=no exit=-13(Permission denied) a0=2 a1=3 a2=ff a3=7fff9a7f28a0 items=0 ppid=2306 pid=2307 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1 comm=iptables exe=/sbin/iptables-multi-1.4.7 subj=unconfined_u:system_r:fail2ban_t:s0 key=(null) type=AVC msg=audit(10/12/2012 11:42:45.288:32) : avc: denied { create } for pid=2307 comm=iptables scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=rawip_socket ---- type=SYSCALL msg=audit(10/12/2012 11:42:45.288:33) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=7f6de4342672 a1=0 a2=0 a3=7fff9a7f2920 items=0 ppid=2306 pid=2307 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1 comm=iptables exe=/sbin/iptables-multi-1.4.7 subj=unconfined_u:system_r:fail2ban_t:s0 key=(null) type=AVC msg=audit(10/12/2012 11:42:45.288:33) : avc: denied { search } for pid=2307 comm=iptables scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir ---- type=SYSCALL msg=audit(10/12/2012 11:42:55.696:55) : arch=x86_64 syscall=execve success=yes exit=0 a0=eb7090 a1=eb7140 a2=eb6f20 a3=7fff8cd753f0 items=0 ppid=2373 pid=2376 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1 comm=sendmail exe=/usr/sbin/sendmail.postfix subj=unconfined_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(10/12/2012 11:42:55.696:55) : avc: denied { read } for pid=2376 comm=sendmail path=inotify dev=inotifyfs ino=1 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir ----
I added some fixes. Let's see if these some of these issues will be fixed.
Looks fixed with selinux-policy-3.7.19-186.el6.noarch. Probably still need to cleanup the sendmail leak, but I don't think that is a policy issue. Thanks!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0314.html