SELinux and Shorewall with IPSets (FC14)

Mr Dash Four mr.dash.four at googlemail.com
Sun Jan 2 22:38:20 UTC 2011


--->Back to the future...--->

I've had this problem in the early days of FC13 (from what I remember 
this was my first post ever in this mailing list), today upgraded to 
FC14 and ... voila... here we go again:

type=AVC msg=audit(1294001576.891:33): avc:  denied  { read } for  
pid=2753 comm="ipset" path="/etc/shorewall/ips/blacklist-eu1.ips" 
dev=dm-0 ino=16488 scontext=unconfined
_u:system_r:iptables_t:s0 tcontext=system_u:object_r:shorewall_etc_t:s0 
tclass=file
type=SYSCALL msg=audit(1294001576.891:33): arch=40000003 syscall=11 
success=yes exit=0 a0=979f3c0 a1=979f520 a2=9794ba0 a3=979f520 items=0 
ppid=2727 pid=2753 auid=500 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 
comm="ipset" exe="/sbin/ipset" subj=unconfined_u:system_r:iptables_t:s0 
key=(null)


Quick scan with sesearch on the policy with FC13 (which works!) reveals 
this:

[zeek at test1 serefpolicy-3.7.19]$ sesearch -A -s iptables_t -t 
shorewall_etc_t
Found 3 semantic av rules:
   allow iptables_t configfile : file { ioctl read getattr lock open } ;
   allow iptables_t configfile : dir { ioctl read getattr lock search 
open } ;
   allow iptables_t configfile : lnk_file { read getattr } ;

While the same command when executed with the newest version of the 
targeted policy on FC14 fetches nothing! So, my questions is - what has 
changed and why?!


More information about the selinux mailing list