Bug 431803 - SELinux prevents saving and restoring iptables configurations
Summary: SELinux prevents saving and restoring iptables configurations
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-firewall   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2008-02-07 01:01 UTC by Andrew Farris
Modified: 2008-02-08 19:44 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-08 03:49:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
selinux_iptables-restor.txt (2.48 KB, text/plain)
2008-02-07 01:04 UTC, Andrew Farris
no flags Details
selinux_iptables-save.txt (3.61 KB, text/plain)
2008-02-07 01:05 UTC, Andrew Farris
no flags Details
selinux_iptables-save-etc_t.txt (3.60 KB, text/plain)
2008-02-07 01:07 UTC, Andrew Farris
no flags Details

Description Andrew Farris 2008-02-07 01:01:43 UTC
Description of problem:
SELinux prevents saving and restoring iptables configurations due to labeling of

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

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. use system-config-firewall to create configuration, click apply to write
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

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

Comment 1 Andrew Farris 2008-02-07 01:04:09 UTC
Created attachment 294176 [details]

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

(at this point the file /etc/sysconfig/iptables is empty and incorrectly
labeled, also the save done by shutdown was denied)

Comment 2 Andrew Farris 2008-02-07 01:05:37 UTC
Created attachment 294177 [details]

iptables-save done by the service shutdown denies writing the file, empty file
is created, service shuts down happily

Comment 3 Andrew Farris 2008-02-07 01:07:20 UTC
Created attachment 294178 [details]

Correctly labeled file /etc/sysconfig/iptables is denied write by
iptables-save, after restorecon.

Comment 4 Daniel Walsh 2008-02-07 15:46:35 UTC
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.

Comment 5 Andrew Farris 2008-02-08 01:56:10 UTC
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

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)

Comment 6 Andrew Farris 2008-02-08 03:49:31 UTC
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.

Comment 7 Thomas Woerner 2008-02-08 11:02:38 UTC
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

Comment 8 Daniel Walsh 2008-02-08 15:29:53 UTC
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.


service iptables save 

is probably the best thing to do.

Comment 9 Andrew Farris 2008-02-08 19:44:33 UTC
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).

Note You need to log in before you can comment on or make changes to this bug.