Hide Forgot
Description of problem: SELinux prevents saving and restoring iptables configurations due to labeling of /etc/sysconfig/iptables. Using a bash script to generate a table and then iptables-save the result to the system configuration is not possible. This also prevents system-config-firewall from writing the new generated default firewall configurations to iptables. As a result the system restarts with no firewall rules applied and all traffic accepted. Version-Release number of selected component (if applicable): selinux-policy-3.2.6-5.fc9.noarch selinux-policy-targeted-3.2.6-5.fc9.noarch Steps to Reproduce: 1. use system-config-firewall to create configuration, click apply to write configuration 2. observe denial due to iptables-save 3. stop, then restart iptables, denial due to iptables-restor This may be related to my typical firewall configuration method, a shell script which directly calls the init scripts, iptables-save, copies the old configuration, calls iptables to add new rules, then saves the new configuration. After the script attempts to iptables-save > /etc/sysconfig/iptables the file /etc/sysconfig/iptables is labeled unconfined_u:object_r:admin_home_t (the script being run is located in /root) - restorecon -v /etc/sysconfig/iptables restorecon reset /etc/sysconfig/iptables context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:etc_t:s0 Running a shell script to do iptables-save (as root) creates a file labeled admin_home_t but the file is empty (rather than having iptables configuration), and cannot be read by iptables when started. SELinux denys access to the file when labeled system_u:object_r:etc_t as well, after relabeling the file with current policy. If the file is removed and current iptables rules added directly by iptables, then the service is stopped and started, it creates the correct saved rules. The problem occurs when root attempts to iptables-save (creating a blank badly labeled file) and then from there onward iptables cannot save its own current configuration, and results in no firewall configuration after stop/start of the service.
Created attachment 294176 [details] selinux_iptables-restor.txt The iptables service cannot start properly, due to the denial attached. 16:22:02 |root:2| |58 files:476K@sysconfig| |0 jobs| - service iptables stop iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ] iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] 16:31:35 |root:2| |58 files:476K@sysconfig| |0 jobs| - service iptables start iptables: Applying firewall rules: Can't open /etc/sysconfig/iptables: Permission denied [FAILED] (at this point the file /etc/sysconfig/iptables is empty and incorrectly labeled, also the save done by shutdown was denied)
Created attachment 294177 [details] selinux_iptables-save.txt iptables-save done by the service shutdown denies writing the file, empty file is created, service shuts down happily
Created attachment 294178 [details] selinux_iptables-save-etc_t.txt Correctly labeled file /etc/sysconfig/iptables is denied write by iptables-save, after restorecon.
system-config-firewall is not creating this file with the correct context. It is creating the file in /root and then mv into place. It needs to add a restorecon /etc/sysconfig/iptables after it is done moving the file, to generate the proper context for the system.
Thanks for looking at this Daniel, but unfortunately I can't even replicate it again using my own scripts that led to this.. so I'll have to keep trying to figure out what set of events really caused it. (I thought I had it figured out, but trying to repeat does not work) It is definitely a dangerous thing that the firewall configuration was completely blanked by this set of save/restor and denials, and whatever else was involved (hard to say since I can't repeat it now). Can I confirm from you that it is desired behavior for the policy to deny iptables-save to an admin_home_t directory (see below), which would copy the configuration to a less confined location? If you do this it is denied, so maybe copying this file to /etc/sysconfig (bad label, empty file) could be what ends up causing the wide open firewall. Note that I cannot even just restore the context this should have after copying it into etc because it literally is an empty file. SELinux is preventing the iptables-save from using potentially mislabeled files (/root/scripts/iptables-inserted). Raw Audit Messages host=cirithungol type=AVC msg=audit(1202435364.481:880): avc: denied { write } for pid=9781 comm="iptables-save" path="/root/scripts/iptables-inserted" dev=sdb3 ino=78928 scontext=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file host=cirithungol type=SYSCALL msg=audit(1202435364.481:880): arch=40000003 syscall=11 success=yes exit=0 a0=93ffe78 a1=9405d10 a2=943e600 a3=0 items=0 ppid=9413 pid=9781 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="iptables-save" exe="/sbin/iptables-save" subj=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 key=(null)
Ok my inability to recreate the mess is partially related to bug# 431961, and I think the denial you were commenting on in #4 was one caused by my script which saves a copy of iptables to home. Now system-config-firewall does not get these denials unless there is some tampering with the configuration already (my scripted save/restore). Also, I guess the way I was saving and restoring the config is not necessary/incorrect. The initscript has 'service iptables save'. This appears to do it correctly without denials, saving to tmp then copying to etc. The file could be copied elsewhere then, copied back, context restored, and it seems to work fine. If the policy denying 'iptables-save > ~/file' is intended, then it would be better to make the policy deny creating the file as well, not just having an empty file result.
To comment #4: This is not correct. /etc/sysconfig/iptables-config is created this way, because the file gets edited. But it is not true for /etc/sysconfig/iptables.
iptables-save > ~/file creates a blank file because of the interaction of two processes. bash creates the empty ~/file and then hands the open descriptors to iptables-save. SELinux sees that iptables-save is a confined process and checks it's access to ~/file (admin_home_t). It sees that iptables-save is not allowed to write there so it closes the file descriptor and replaces it with /dev/null. As a hack way around this you could do. iptables-save | cat > ~/file And it will work. But service iptables save is probably the best thing to do.
Ok that makes sense and it is a reasonable result to get the empty file then, thanks Dan. I'll close this and reopen if I end up with the same context issue on the service doing its own configuration save (without poking it improperly first).