James B. Byrne
2015-Jan-19 16:50 UTC
[CentOS] CentOS-6.6 Fail2Ban and Postfix Selinux AVCs
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.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
James B. Byrne
2015-Jan-19 18:59 UTC
[CentOS] CentOS-6.6 Fail2Ban and Postfix Selinux AVCs
On Mon, January 19, 2015 11:50, James B. Byrne wrote:> 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 > >It appears that the starting date of these errors corresponds to the day on which we first began to jail SSH attempts on that host. We eventually ended up with a custom policy that looks like this: #============= fail2ban_t =============allow fail2ban_t ldconfig_exec_t:file { read execute open getattr execute_no_trans }; allow fail2ban_t insmod_exec_t:file { read execute open }; allow fail2ban_t self:capability { net_admin net_raw }; allow fail2ban_t self:rawip_socket { getopt create setopt }; allow fail2ban_t sysctl_kernel_t:dir search; allow fail2ban_t sysctl_modprobe_t:file read; allow system_mail_t inotifyfs_t:dir read; I am not sure whether this issue is the result of something that we have done or left undone. We have another host configured in much the same fashion as this one and it does not display these errors. On the other hand the second host was installed several years ago and has a number of custom polices already applied. It is possible that this problem was dealt with piecemeal or is submerged due to other customisations. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Daniel J Walsh
2015-Jan-21 14:42 UTC
[CentOS] CentOS-6.6 Fail2Ban and Postfix Selinux AVCs
On 01/19/2015 01:59 PM, James B. Byrne wrote:> On Mon, January 19, 2015 11:50, James B. Byrne wrote: >> 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 >> >> > It appears that the starting date of these errors corresponds to the > day on which we first began to jail SSH attempts on that host. > > We eventually ended up with a custom policy that looks like this: > > #============= fail2ban_t =============> allow fail2ban_t ldconfig_exec_t:file { read execute open getattr > execute_no_trans }; > > allow fail2ban_t insmod_exec_t:file { read execute open }; > allow fail2ban_t self:capability { net_admin net_raw }; > allow fail2ban_t self:rawip_socket { getopt create setopt }; > allow fail2ban_t sysctl_kernel_t:dir search; > allow fail2ban_t sysctl_modprobe_t:file read; > > allow system_mail_t inotifyfs_t:dir read;THese avc's are related to fail2ban inserting kernel modules, which seems like a dangerous thing to do.> > I am not sure whether this issue is the result of something that we > have done or left undone. We have another host configured in much the > same fashion as this one and it does not display these errors. On the > other hand the second host was installed several years ago and has a > number of custom polices already applied. It is possible that this > problem was dealt with piecemeal or is submerged due to other > customisations. >