Hello all,

As part of my security set-up I use, amongst other things, fail2ban.
This has many well known problems with SELinux but, with help from this
list in general and Dominick Grift in particular, I got a policy which
has worked without problems since (see the thread here:
https://www.redhat.com/archives/fedora-selinux-list/2009-December/msg00082.html)

This culminated in the following policy:
policy_module(myfail2ban, 11.2.1)
optional_policy(`
gen_require(`
attribute domain;
type fail2ban_t;
')
dontaudit domain fail2ban_t:unix_stream_socket { read write };
')


Today, F2B successfully blocked a probing attempt. The offender's IP
address is "dropped" in iptables, and the F2B server sent me an email to
inform me of the ban (all as expected). Two slightly strange, and
possibly unrelated things however...

1) The ban was not recorded in F2B's own log
2) I got (at exactly the time of the banning action) the following 2
AVCs:

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1271226504.162:64635): avc: denied { read write } for pid=25646 comm="iptables" path="socket:[1307085]" dev=sockfs ino=1307085 scontext=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_dgram_socket
node=troodos.org.uk type=SYSCALL msg=audit(1271226504.162:64635): arch=40000003 syscall=11 success=yes exit=0 a0=84a4e28 a1=84a50a8 a2=84a3a28 a3=84a50a8 items=0 ppid=25645 pid=25646 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 key=(null)

Raw Audit Messages :

node=troodos.org.uk type=AVC msg=audit(1271226505.377:64636): avc: denied { read write } for pid=25652 comm="iptables" path="socket:[1307085]" dev=sockfs ino=1307085 scontext=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_dgram_socket
node=troodos.org.uk type=SYSCALL msg=audit(1271226505.377:64636): arch=40000003 syscall=11 success=yes exit=0 a0=836c018 a1=836bff0 a2=836aa28 a3=836bff0 items=0 ppid=2672 pid=25652 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 key=(null)

Audit2allow thinks this:

# cat avcs | audit2allow -M test
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i test.pp

# cat test.te

module test 1.0;

require {
type unconfined_t;
type iptables_t;
class unix_dgram_socket { read write };
}

#============= iptables_t ==============
allow iptables_t unconfined_t:unix_dgram_socket { read write };


The logging problem aside, F2B seems to have worked as normal. Should I
include the above things in my policy or is there another approach?

Thanks for any suggestions.

Mark

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

On Wed, Apr 14, 2010 at 10:17 AM, Arthur Dent <misc.lists@blueyonder.co.uk> wrote:

Hello all,



As part of my security set-up I use, amongst other things, fail2ban.

This has many well known problems with SELinux but, with help from this

list in general and Dominick Grift in particular, I got a policy which

has worked without problems since (see the thread here:

https://www.redhat.com/archives/fedora-selinux-list/2009-December/msg00082.html)


Strange that iptables live in the unconfined_r role : should be system_u:system_r:iptables_t ?


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux