[CentOS] CentOS-6.6 Fail2Ban and Postfix Selinux AVCs

[Daniel J Walsh]

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.
>