Description of problem: When starting Shorewall I get two new AVCs (this only happens with iptables 1.4.12.2, the previous version - 1.4.10 was OK) - see below for details Version-Release number of selected component (if applicable): iptables 1.4.12.2, policy 3.9.16-50 How reproducible: Always Steps to Reproduce: 1. Shorewall start at boot up; or 2. shorewall start 3. Actual results: type=AVC msg=audit(1329780327.357:30545): avc: denied { module_request } for pid=2507 comm="iptables-restor" kmod="iptable_raw" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system type=AVC msg=audit(1329780327.706:30550): avc: denied { module_request } for pid=2507 comm="iptables-restor" kmod="ipt_addrtype" scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system Shorewall fails to start with the following message: Feb 20 23:18:09 test1 shorewall[1432]: iptables-restore v1.4.12.2: iptables-restore: unable to initialize table 'raw' Please note that When Shorewall is started at bootup NO AVCs are shown in the audit log (may be this is another bug!), but Shorewall is still prevented from loading/requesting the kernel modules. The above 2 errors are shown subsequently when I start it from the command line. Expected results: Shorewall to start normally. Additional info: The above two errors started happening when I did 2 things on this machine: upgraded the kernel to 3.2 and upgraded iptables to 1.4.12.2 (I had 3.1 and iptables 1.4.10 previously)
Well, there should be a transition. How is labeled "iptables-restore" on your F15 system? $ ls -Z /usr/sbin/xtables-multi -rwxr-xr-x. root root system_u:object_r:iptables_exec_t:s0 /usr/sbin/xtables-multi
OK, I found the following: 1. All iptables files are located in /sbin, not /usr/sbin: 2. The label on those files is not iptables_exec_t, but the "default" - bin_t: [root@test1 ~]# whereis iptables iptables: /sbin/iptables /usr/share/man/man8/iptables.8.gz [root@test1 ~]# ls -lasZ /sbin/ipt* lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin/iptables -> xtables-multi lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin/iptables-restore -> xtables-multi lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin/iptables-save -> xtables-multi -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /sbin/iptaccount -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /sbin/iptunnel [root@xp1 ~]# ls -lasZ /sbin/xtables-multi -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /sbin/xtables-multi Now, since I compiled and installed iptables from source, I also checked the .spec file in iptables' SRPM: ./configure --enable-devel --enable-libipq --bindir=/bin --sbindir=/sbin --sysconfdir=/etc --libdir=/%{_lib} --libexecdir=/%{_lib} --mandir=%{_mandir} --includedir=%{_includedir} --with-kernel=/usr --with-kbuild=/usr --with-ksource=/usr As evident from the above, Fedora's own installation directory is /sbin, not /usr/sbin. That makes perfect sense and complies fully with FHS, so I guess you may have to amend the policy. In the mean time I did this as a work-around: semanage fcontext -a -t iptables_exec_t "/sbin/iptables" semanage fcontext -a -t iptables_exec_t "/sbin/iptables-restore" semanage fcontext -a -t iptables_exec_t "/sbin/iptables-save" semanage fcontext -a -t iptables_exec_t "/sbin/xtables-multi" followed up by the appropriate restorecon and after a restart all is well!
Scratch that...it turned out I was in permissive mode (I did switch it on yesterday to find out what was causing shorewall to fail). When I now try to start shorewall with the newly relabelled files, I get this: type=AVC msg=audit(1329871127.241:27523): avc: denied { read } for pid=2026 comm="shorewall" name="iptables" dev=dm-0 ino=131343 scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1329871127.241:27523): arch=c000003e syscall=4 success=no exit=-13 a0=a97090 a1=7ffff64a44e0 a2=7ffff64a44e0 a3=8 items=0 ppid=2018 pid=2026 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="shorewall" exe="/bin/bash" subj=unconfined_u:system_r:shorewall_t:s0 key=(null) as well as: type=AVC msg=audit(1329871173.761:27532): avc: denied { getattr } for pid=2286 comm="iptables-restor" name="/" dev=proc ino=1 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem type=SYSCALL msg=audit(1329871173.761:27532): arch=c000003e syscall=137 success=yes exit=0 a0=32e8608ade a1=7fffd178c2c0 a2=7fffd178c230 a3=3c86a15ca2 items=0 ppid=2217 pid=2286 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="iptables-restor" exe="/sbin/xtables-multi" subj=unconfined_u:system_r:iptables_t:s0 key=(null) Rebooted, just to make sure - it is even worse: shorewall can't start and I can't get any audit messages (there is nothing in my syslog either) and the above 2 AVCs are only shown when I try to start shorewall manually. Over to you...
Update 2: when I restore the original label of all symlinked files (/sbin/iptables*) to their previous value (bin_t), leaving just xtables-multi with "iptables_exec_t" then all is well and shorewall starts normally, so I guess the only change needed is for /sbin/xtables-multi to be labelled properly. Let me know if you need anything else from me.
Good analysis ;-). commit 4f414723df906a5707c8a4265d6049674b23bdf1 Author: Miroslav Grepl <mgrepl> Date: Wed Feb 22 15:24:40 2012 +0000 Add label for /sbin/xtables-multi
I've just spotted another gem: type=AVC msg=audit(1330130759.095:14): avc: denied { getattr } for pid=1615 comm="iptables-restor" name="/" dev=proc ino=1 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem type=SYSCALL msg=audit(1330130759.095:14): arch=c000003e syscall=137 success=no exit=-13 a0=32e8608ade a1=7fff81616130 a2=7fff816160a0 a3=3c86a15ca2 items=0 ppid=1550 pid=1615 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables-restor" exe="/sbin/xtables-multi" subj=system_u:system_r:iptables_t:s0 key=(null)
selinux-policy-3.9.16-52.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-52.fc15
The getattr avc (as shown in Comment 6 above ) is STILL present in -52 version of the policy!
The policy has kernel_read_system_state(iptables_t) so it should be allowed. If you reinstall the policy $ yum reinstall selinux-policy-targeted does it blow up?
Using the -53 version and trying "shorewall restart" I still get this: time->Sat Mar 17 00:26:08 2012 type=SYSCALL msg=audit(1331943968.767:30596): arch=c000003e syscall=137 success=no exit=-13 a0=32e8608ade a1=7fff506adf20 a2=7fff506ade90 a3=3c86a15ca2 items=0 ppid=15716 pid=15774 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="iptables-restor" exe="/sbin/xtables-multi" subj=unconfined_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(1331943968.767:30596): avc: denied { getattr } for pid=15774 comm="iptables-restor" name="/" dev=proc ino=1 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem It can't be mis-labelling because the source context is clearly iptables_t and the target is proc_t. I don't know whether it matters that shorewall executes iptables. It is also worth noting that I get this avc only with the 1.4.12 version of iptables - I didn't have this problem with 1.4.10.
We allow this in F17.
Yes and I see it also in F15.
Package selinux-policy-3.9.16-52.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-52.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4286/selinux-policy-3.9.16-52.fc15 then log in and leave karma (feedback).
selinux-policy-3.9.16-52.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.