I am seeing these in the log of one of our off-site NX hosts running CentOS-6.6.
type=AVC msg=audit(1421683972.786:4372): avc: denied { create } for pid=22788 comm="iptables" scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=rawip_socket Was caused by: Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
SELinux is preventing /sbin/iptables-multi-1.4.7 from search access on the directory .
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that iptables-multi-1.4.7 should be allowed search access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep iptables /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
I presume that the following is somehow related to that host sending out mail, possible by fail2ban, since we run postfix on that host and the sendmail SMTP package is not installed.
type=AVC msg=audit(1421683972.826:4376): avc: denied { read } for pid=22796 comm="sendmail" path="inotify" dev=inotifyfs ino=1 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir Was caused by: Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
SELinux is preventing /usr/sbin/sendmail.postfix from read access on the directory inotify.
***** Plugin leaks (86.2 confidence) suggests ******************************
If you want to ignore sendmail.postfix trying to read access the inotify directory, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # grep /usr/sbin/sendmail.postfix /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp
***** Plugin catchall (14.7 confidence) suggests ***************************
If you believe that sendmail.postfix should be allowed read access on the inotify directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sendmail /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
We are nonetheless receiving fail2ban email notifications from that host. Therefore I am not sure what this avc is telling us.
We use Fail2Ban on a number of other Inetenet facing hosts. We have not yet detected anything similar on those, although until this morning's descovery we never really looked for this situation specifically.
To check and see if anything was off kilter in the contexts I ran restorcon -Rv on /sbin and on /usr and restarted Fail2Ban. When I reviewed the log file I found these in /var/log/messages.
setroubleshoot: [avc.ERROR] Plugin Exception restorecon #012Traceback (most recent call last):#012 File "/usr/lib64/python2.6/site-packages/setroubleshoot/analyze.py", line 191, in analyze_avc#012 report = plugin.analyze(avc)#012 File "/usr/share/setroubleshoot/plugins/restorecon.py", line 99, in analyze#012 if avc.tpath[0] != '/': return None#012IndexError: string index out of range
Checking back I discovered that these first appeared in our log on January 4. Yum history indicates that there were updates on Jan 2 and Jan 8. The Jan 2 update was to Webmin alone. I doubt that had anything to do with this.
I am not sure what to think at them moment. Is there something wrong with SETroubleShoot?
I can work around these avcs with a local policy but in the event the issue is not our error this may have wider implications so I am posting the details here.
I am also seeing avcs relating to bash accessing ldconfig.