fail2ban with ipset fails when selinux enforceing?

[Charles Bradshaw]

I'm running Fedora 17, kernel 3.9.10-100.fc17.i686.PAE

I am configuring ipset as an addition to fail2ban which I have had working for some time.

I have this fail2ban-fixes.te compiled and installed:
module fail2ban-fixes 1.02;

# created using:
# cat /var/log/audit/audit.log | audit2allow -m local > local.te
# and moving local.te here.
#
# Modification:
# 1.00 May 28 2013 fail2ban_client_t
# 1.01 Jun 15 2013 logrotate_t
# 1.02 Sep 16 2013 fail2ban_t

# 1.00 - allow fail2ban client access to http logs
#
require {
    type httpd_log_t;
    type fail2ban_var_run_t;
    type fail2ban_client_t;
    class di31.7.144.66r { read write search };
}

#============= fail2ban_client_t ==============
allow fail2ban_client_t fail2ban_var_run_t:dir write;
allow fail2ban_client_t httpd_log_t:dir read;
allow fail2ban_client_t httpd_log_t:dir search;

# 1.01 - allow fail2ban logrotate
#
require {
    type logrotate_t;
    type fail2ban_client_exec_t;
    class file { read execute open };
}

#============= logrotate_t ==============
allow logrotate_t fail2ban_client_exec_t:file { read execute };

# 1.02 allow fail2ban access to ipset NOT WORKING when enforcing !
# 
require {
    type fail2ban_t;
    class netlink_socket { bind create getattr };
        class capability net_admin;
}

#============= fail2ban_t ==============
allow fail2ban_t self:netlink_socket { bind create getattr };
allow fail2ban_t self:capability net_admin;

All of the above have been created using audit2allow.

The last block of the above, 'fail2ban_t', is necessary to get ipset to work the previous were 
necessary to allow the fail2ban client.

As long as I am in permissive mode there are NO failed records in /var/log/audit/audit.log and 
'nothing to do' reported by audit2allow.

The ipset command is:
ipset --test fail2ban-forum 198.143.143.5 || ipset --add fail2ban-forum 198.143.143.5
and the correct entry is made to the hash:ip set fail2ban-forum. (that is as long as we are permissive)

However, when enforcing is enabled the fail2ban.log contains errors like this:
2013-09-16 21:32:24,750 fail2ban.actions.action: ERROR  ipset --test fail2ban-forum 198.143.143.5 ||  ipset --add fail2ban-forum 198.143.143.5 returned 100

I can, of course, execute the ipset commands as root when enforcing.

Here's the problem:
There is nothing in /var/log/audit/audit.log or /var/log/messages to diagnose the nature of the error!

Where is the bug? selinux or ipset or somewhere else?
How do I debug the problem?

Any clues much appreciated. I am cross posting this to the fail2ban list.

TIA Charles Bradshaw

[Dominick Grift]

On Mon, 2013-09-16 at 23:15 +0100, Charles Bradshaw wrote:
> I'm running Fedora 17, kernel 3.9.10-100.fc17.i686.PAE
>
> I am configuring ipset as an addition to fail2ban which I have had working for some time.
>
> I have this fail2ban-fixes.te compiled and installed:
> module fail2ban-fixes 1.02;
>
> # created using:
> # cat /var/log/audit/audit.log | audit2allow -m local > local.te
> # and moving local.te here.
> #
> # Modification:
> # 1.00 May 28 2013 fail2ban_client_t
> # 1.01 Jun 15 2013 logrotate_t
> # 1.02 Sep 16 2013 fail2ban_t
>
> # 1.00 - allow fail2ban client access to http logs
> #
> require {
>    type httpd_log_t;
>    type fail2ban_var_run_t;
>    type fail2ban_client_t;
>    class di31.7.144.66r { read write search };
> }
>
> #============= fail2ban_client_t ==============
> allow fail2ban_client_t fail2ban_var_run_t:dir write;
> allow fail2ban_client_t httpd_log_t:dir read;
> allow fail2ban_client_t httpd_log_t:dir search;
>
> # 1.01 - allow fail2ban logrotate
> #
> require {
>    type logrotate_t;
>    type fail2ban_client_exec_t;
>    class file { read execute open };
> }
>
> #============= logrotate_t ==============
> allow logrotate_t fail2ban_client_exec_t:file { read execute };
>
> # 1.02 allow fail2ban access to ipset NOT WORKING when enforcing !
> # 
> require {
>    type fail2ban_t;
>    class netlink_socket { bind create getattr };
>         class capability net_admin;
> }
>
> #============= fail2ban_t ==============
> allow fail2ban_t self:netlink_socket { bind create getattr };
> allow fail2ban_t self:capability net_admin;
>
> All of the above have been created using audit2allow.
>
> The last block of the above, 'fail2ban_t', is necessary to get ipset to work the previous were 
> necessary to allow the fail2ban client.
>
> As long as I am in permissive mode there are NO failed records in /var/log/audit/audit.log and 
> 'nothing to do' reported by audit2allow.
>
> The ipset command is:
> ipset --test fail2ban-forum 198.143.143.5 || ipset --add fail2ban-forum 198.143.143.5
> and the correct entry is made to the hash:ip set fail2ban-forum. (that is as long as we are permissive)
>
> However, when enforcing is enabled the fail2ban.log contains errors like this:
> 2013-09-16 21:32:24,750 fail2ban.actions.action: ERROR  ipset --test fail2ban-forum 198.143.143.5 ||  ipset --add fail2ban-forum 198.143.143.5 returned 100
>
> I can, of course, execute the ipset commands as root when enforcing.
>
> Here's the problem:
> There is nothing in /var/log/audit/audit.log or /var/log/messages to diagnose the nature of the error!
>
> Where is the bug? selinux or ipset or somewhere else?
> How do I debug the problem?
>
> Any clues much appreciated. I am cross posting this to the fail2ban list.

Some events are silently prevented by SELinux using rules with the
dontaudit keyword.

You can build the policy without those "dontaudit"  rules inserted:

semodule -DB

Then you can reproduce your issues, and any event that were previously
silently prevented will now be exposed in audit.log

To build the policy with the "dontaudit"  rules re-inserted:

semodule -B

silently preventing events is generally done for good reason. However,
everyone once in a while we get "dontaudit-happy", and add dontaudit
rules that we really shouldnt add. I guess were all just human after
all...
> TIA Charles Bradshaw
>
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux