RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 865567 - avc denials on fail2ban restart
Summary: avc denials on fail2ban restart
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.3
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-11 19:10 UTC by Orion Poplawski
Modified: 2013-02-21 08:31 UTC (History)
3 users (show)

Fixed In Version: selinux-policy-3.7.19-184.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:31:15 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0314 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2013-02-20 20:35:01 UTC

Description Orion Poplawski 2012-10-11 19:10:16 UTC 
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
Comment 2 Daniel Walsh 2012-10-12 02:30:30 UTC 
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.
Comment 3 Milos Malik 2012-10-12 08:08:33 UTC 
# 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 
----
Comment 4 Miroslav Grepl 2012-10-15 18:55:38 UTC 
I added some fixes. Let's see if these some of these issues will be fixed.
Comment 18 Orion Poplawski 2012-12-14 17:46:02 UTC 
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!
Comment 20 errata-xmlrpc 2013-02-21 08:31:15 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.