Bug 431803 - SELinux prevents saving and restoring iptables configurations
SELinux prevents saving and restoring iptables configurations
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: system-config-firewall (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-06 20:01 EST by Andrew Farris
Modified: 2008-02-08 14:44 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-07 22:49:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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-06 20:04 EST, Andrew Farris
no flags Details
selinux_iptables-save.txt (3.61 KB, text/plain)
2008-02-06 20:05 EST, Andrew Farris
no flags Details
selinux_iptables-save-etc_t.txt (3.60 KB, text/plain)
2008-02-06 20:07 EST, Andrew Farris
no flags Details

  None (edit)
Description Andrew Farris 2008-02-06 20:01:43 EST
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.
Comment 1 Andrew Farris 2008-02-06 20:04:09 EST
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)
Comment 2 Andrew Farris 2008-02-06 20:05:37 EST
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
Comment 3 Andrew Farris 2008-02-06 20:07:20 EST
Created attachment 294178 [details]
selinux_iptables-save-etc_t.txt

Correctly labeled file /etc/sysconfig/iptables is denied write by
iptables-save, after restorecon.
Comment 4 Daniel Walsh 2008-02-07 10:46:35 EST
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-07 20:56:10 EST
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)
Comment 6 Andrew Farris 2008-02-07 22:49:31 EST
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 06:02:38 EST
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.
Comment 8 Daniel Walsh 2008-02-08 10:29:53 EST
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.

Comment 9 Andrew Farris 2008-02-08 14:44:33 EST
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.