Bug 431803

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).