Red Hat Bugzilla – Bug 615083
SELinux is preventing /sbin/iptables-multi access to a leaked /root/iptables-default.txt file descriptor.
Last modified: 2010-09-15 08:27:08 EDT
Summary: SELinux is preventing /sbin/iptables-multi access to a leaked /root/iptables-default.txt file descriptor. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by the iptables-save command. It looks like this is either a leaked descriptor or iptables-save output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /root/iptables-default.txt. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context unconfined_u:unconfined_r:iptables_t:s0 Target Context unconfined_u:object_r:admin_home_t:s0 Target Objects /root/iptables-default.txt [ file ] Source iptables-save Source Path /sbin/iptables-multi Port <Unknown> Host (removed) Source RPM Packages iptables-1.4.7-2.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-33.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name leaks Host Name (removed) Platform Linux (removed) 2.6.33.6-147.fc13.i686 #1 SMP Tue Jul 6 22:30:55 UTC 2010 i686 i686 Alert Count 1 First Seen Thu 15 Jul 2010 02:25:42 PM PDT Last Seen Thu 15 Jul 2010 02:25:42 PM PDT Local ID 9f7aff4a-7ff0-4252-92d2-123c83aafa73 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1279229142.637:59): avc: denied { write } for pid=6291 comm="iptables-save" path="/root/iptables-default.txt" dev=dm-0 ino=3317900 scontext=unconfined_u:unconfined_r:iptables_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1279229142.637:59): arch=40000003 syscall=11 success=yes exit=0 a0=8592d50 a1=85b0878 a2=85aa470 a3=85b0878 items=0 ppid=5109 pid=6291 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="iptables-save" exe="/sbin/iptables-multi" subj=unconfined_u:unconfined_r:iptables_t:s0 key=(null) Hash String generated from leaks,iptables-save,iptables_t,admin_home_t,file,write audit2allow suggests: #============= iptables_t ============== allow iptables_t admin_home_t:file write;
This is on a system that was upgraded directly from Fedora 11 to Fedora 13 using pre-upgrade. Yes, the pre-upgrade worked quite nicely. There may be some lingering SELinux file labeling issues. However, this particular issue shouldn't be one of them. For this particular instance, I'm dumping the current iptables to a file so I can figure out how to allow multicasting applications to work. With the firewall disabled, multicasting (in this case, Tomcat 6.0.28 clustering) works as expected. I issued the following command as root: iptables-save > iptables-default.txt This of course generates a nice file for me to study. It also generated the SELinux error above.
We don't want to allow the iptables_t domain this access. #============= iptables_t ============== allow iptables_t admin_home_t:file write; A trick you could use iptables-save | cat > ~/somefile Or just add the allow rule using audit2allow # grep iptables /var/log/audit/audit.log | audit2allow -M myiptables # semodule -i myiptables.pp
OK. Thanks for the trick. I'll use the trick rather than adding a rule. I imagine there are security reasons for this (although I performed the initial operation as root).
mdeggers we are trying to prevent processes from writing to the /root directory. If a process is allowed to write to the root directory than it could write ~/.bashrc. Next time the administrator executed a shell, his machine would be taken over. SELinux is all about controlling processes actions. We are not concerned about securing iptables so much as the applications that have to call iptables. For example networkmanager or dclient might need to call iptables and those apps could be confused by untrusted data downloaded from the net. We want to do our best to make sure these apps can be confined from taking over the entire machine.