Another Fail2ban problem (I think)

Arthur Dent misc.lists at blueyonder.co.uk
Wed Apr 14 08:17:13 UTC 2010


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20100414/12e6c9bc/attachment.bin 


More information about the selinux mailing list