Bug 916727

We need to grab the file_context file before the update and compare it to the file context file after the update and see if the labels changed, if they did, fixfiles -C file_context.pre in post install should have fixed this.

We really need to test this in qe.  
Basically have most everything installed for RHEL6.3

run 

restorecon -R -v /

Now do a yum update

restorecon -R -v / 

SHould report nothing, if there is problems then it is a bug in the update.

With that patch applied to iptables package there i no output at all.

Without iptables restorecon patching there are iptables binaries in bin_t.

Fixed in /policycoreutils-2.1.14-11.el7

Output of testing for reference:

restorecon reset /var/run/lvm context system_u:object_r:var_run_t:s0->system_u:object_r:lvm_var_run_t:s0
restorecon reset /usr/lib64/games context system_u:object_r:lib_t:s0->system_u:object_r:games_exec_t:s0
restorecon reset /sbin/ip6tables-multi-1.4.7 context system_u:object_r:bin_t:s0->system_u:object_r:iptables_exec_t:s0
restorecon reset /sbin/iptables-multi-1.4.7 context system_u:object_r:bin_t:s0->system_u:object_r:iptables_exec_t:s0

Test output when updated with patched policycoreutils

restorecon reset /var/run/lvm context system_u:object_r:var_run_t:s0->system_u:object_r:lvm_var_run_t:s0

Before "yum update" (RHEL-6.3 is installed on the machine)
====================================
# ls -Z /sbin/ip*tables*
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/ip6tables -> ip6tables-multi
-rwxr-xr-x. root root system_u:object_r:iptables_exec_t:s0 /sbin/ip6tables-multi
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/ip6tables-restore -> ip6tables-multi
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/ip6tables-save -> ip6tables-multi
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/iptables -> iptables-multi
-rwxr-xr-x. root root system_u:object_r:iptables_exec_t:s0 /sbin/iptables-multi
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/iptables-restore -> iptables-multi
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/iptables-save -> iptables-multi
# restorecon -Rv /
restorecon reset /etc/motd.orig context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0
restorecon reset /etc/motd context unconfined_u:object_r:etc_t:s0->unconfined_u:object_r:etc_runtime_t:s0
restorecon reset /etc/syslog.conf context unconfined_u:object_r:etc_t:s0->unconfined_u:object_r:syslog_conf_t:s0
restorecon reset /var/log/yum.log context system_u:object_r:var_log_t:s0->system_u:object_r:rpm_log_t:s0
#

After "yum update" (the machine was updated to RHEL-6.4)
====================================
# ls -Z /sbin/ip*tables*
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /sbin/ip6tables -> /etc/alternatives/ip6tables.i386
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/ip6tables-1.4.7 -> ip6tables-multi
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /sbin/ip6tables-multi -> /etc/alternatives/sbin-ip6tables-multi.i386
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /sbin/ip6tables-multi-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /sbin/ip6tables-restore -> /etc/alternatives/sbin-ip6tables-restore.i386
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/ip6tables-restore-1.4.7 -> ip6tables-multi
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /sbin/ip6tables-save -> /etc/alternatives/sbin-ip6tables-save.i386
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/ip6tables-save-1.4.7 -> ip6tables-multi
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /sbin/iptables -> /etc/alternatives/iptables.i386
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/iptables-1.4.7 -> iptables-multi
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /sbin/iptables-multi -> /etc/alternatives/sbin-iptables-multi.i386
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /sbin/iptables-multi-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /sbin/iptables-restore -> /etc/alternatives/sbin-iptables-restore.i386
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/iptables-restore-1.4.7 -> iptables-multi
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /sbin/iptables-save -> /etc/alternatives/sbin-iptables-save.i386
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/iptables-save-1.4.7 -> iptables-multi
# restorecon -Rv /
restorecon reset /var/run/lvm context system_u:object_r:var_run_t:s0->system_u:object_r:lvm_var_run_t:s0
restorecon reset /sbin/iptables-multi-1.4.7 context system_u:object_r:bin_t:s0->system_u:object_r:iptables_exec_t:s0
restorecon reset /sbin/ip6tables-multi-1.4.7 context system_u:object_r:bin_t:s0->system_u:object_r:iptables_exec_t:s0
#

Created attachment 704153 [details]
/etc/selinux/targeted/contexts/files/file_contexts on RHEL-6.3 machine

Created attachment 704154 [details]
/etc/selinux/targeted/contexts/files/file_contexts on RHEL-6.3 machine updated to RHEL-6.4

To see where the symlinks are pointing:
========================
# ls -Z /etc/alternatives/*ip*tables*
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/bin-iptables-xml.i386 -> /bin/iptables-xml-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/ip6tables.i386 -> /sbin/ip6tables-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/iptables.i386 -> /sbin/iptables-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/man-ip6tables.i386 -> /usr/share/man/man8/ip6tables-1.4.7.8.gz
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/man-ip6tables-restore.i386 -> /usr/share/man/man8/ip6tables-restore-1.4.7.8.gz
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/man-ip6tables-save.i386 -> /usr/share/man/man8/ip6tables-save-1.4.7.8.gz
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/man-iptables.i386 -> /usr/share/man/man8/iptables-1.4.7.8.gz
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/man-iptables-restore.i386 -> /usr/share/man/man8/iptables-restore-1.4.7.8.gz
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/man-iptables-save.i386 -> /usr/share/man/man8/iptables-save-1.4.7.8.gz
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/man-iptables-xml.i386 -> /usr/share/man/man8/iptables-xml-1.4.7.8.gz
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/sbin-ip6tables-multi.i386 -> /sbin/ip6tables-multi-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/sbin-ip6tables-restore.i386 -> /sbin/ip6tables-restore-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/sbin-ip6tables-save.i386 -> /sbin/ip6tables-save-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/sbin-iptables-multi.i386 -> /sbin/iptables-multi-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/sbin-iptables-restore.i386 -> /sbin/iptables-restore-1.4.7
lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0   /etc/alternatives/sbin-iptables-save.i386 -> /sbin/iptables-save-1.4.7
#

*** Bug 916816 has been marked as a duplicate of this bug. ***

About what I would expect.  Not bad, not sure we can fix /var/run/lvm.  Might be an init script creating this with the wrong label.

THe fix to fixfiles should fix the iptables problems.

if shorewall was working in 6.3 but not after upgrade to 6.4 then it's a regression! so it should have to fixed!

Yes we should fix this so it does not happen on the next upgrade, but we will bot be pulling the 6.4 update to fix it.

So you don't think it is a serious security issue that the latest update disables two key security components? (admittedly not part of the core product). Interesting. I would have thought this was as a high impact security errata.

Phil if you are saying iptables rules now run as initrc_t rather then iptables_t, they you are correct, but this is equivalent of SELinux disabled or permissive for iptables.  Not nice but not a huge security problem.

Is there something else that I am missing?

For me, all calls to iptables by fail2ban were blocked.  This meant that fail2ban basically did nothing when it should have been blacklisting IPs after 5 failed connection attempts or other dodgy activity detection I have configured.

While it doesn't directly open a hole to the system, it is one less layer of defence against attacks.  Some are required to run fail2ban for compliance reasons - having it suddenly stop upon upgrading to 6.4 isn't ideal.

Simply re-labelling it fixed it for me, but I suspect there are a lot of users out there who think they have a functioning fail2ban/shorewall setup when in fact they don't after the latest update.

I'm not sure what happens with shorewall. I use the standard iptables scripts which are working fine.  The impact on shorewall is possibly worse - Levente?

Maybe you don't see it as important as shorewall and fail2ban aren't actually part of RHEL, however this bug breaks compatibility in a minor version update - something you guarantee.

I agree it is a problem but don't really see an easy fix for it at this point.

I just had the same problem, after updating from 6.3 to 6.4, I can't reach the server through ssh and apache server does not show anything, well I have to disabled the selinux and solve the problem but create a new one I can not leave selinux disabled it has to be enforcing. I was reading the whole topic and it seems to be a selinux problem with "iptables" I have tried all the possible corrections but I had no luck. Hope you find the fix soon.

cesarhv: there is very simple work-around for this problem.

run command:

restorecon -v /sbin/ip*-multi-1.4.7

if it's so simple then why not create an update selinux package with this in the post install of the rpm???

Because the bug causing this is in policycoreutils.

then an updated policycoreutils?:-)

We will.

 Tuomo Soini: it works, but the problem continues, what i noticed is that the problem is in the bonded interface after the upgrade 6.3 to 6.4. I will look for similar problems. Thank you

*** Bug 922281 has been marked as a duplicate of this bug. ***

I agree with  Phil Anderson , when i have upgraded my servers ,
I did not see immediately that fail2ban was not functional .

This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

It looks there is a bug in fixfiles. Could you test it with

@@ -107,8 +107,8 @@
 	    grep '^[<>]'|cut -c3-| grep ^/ | \
 	    egrep -v '(^/home|^/root|^/tmp|^/dev)' |\
 	sed -r -e 's,[[:blank:]].*,,g' \
-               -e 's|\(([/[:alnum:]]+)\)\?|{\1,}|g' \
-	       -e 's|([/[:alnum:]])\?|{\1,}|g' \
+               -e 's|\(([/[:alnum:]]+)\)\?|\1|g' \
+	       -e 's|([/[:alnum:]])\?|\1|g' \
                -e 's|\?.*|*|g' \
 	       -e 's|\(.*|*|g' \
 	       -e 's|\[.*|*|g' \


Basically you can do more tests if you define

# cp /etc/selinux/targeted/contexts/files/file_contexts /etc/selinux/targeted/contexts/files/file_contexts.old

Then you can change some labels in 

/etc/selinux/targeted/contexts/files/file_contexts.old 

and see how it works.

Also the following could be helpful

             done | \
-		      ${RESTORECON} -i -f - -R -p  `exclude_dirs`; \
+		      ${RESTORECON} -f - -R -p  `exclude_dirs`; \

to see which contexts are passed.

I got it!

The problem is in setfiles/restore.c:

371         if (glob(name,
372                  GLOB_TILDE | GLOB_PERIOD,
373                  NULL,
374                  &globbuf) >= 0) {

because glob() is called without GLOB_BRACE flag. This patch solves it:

--- restore_orig.c	2013-10-14 18:28:25.791769979 +0200
+++ restore.c	2013-10-14 18:29:53.324557073 +0200
@@ -369,7 +369,7 @@
 	memset(&globbuf, 0, sizeof(globbuf));
 	globbuf.gl_offs = 0;
 	if (glob(name,
-		 GLOB_TILDE | GLOB_PERIOD,
+		 GLOB_TILDE | GLOB_PERIOD | GLOB_BRACE,
 		 NULL,
 		 &globbuf) >= 0) {
 		for (i = 0; i < globbuf.gl_pathc; i++) {

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1608.html

I don't see the fix for this in released version. Is this really fixed?

Not sure why there are private messages, but I made them public so people can see what we attempted to fix.

Ok. So there is totally different fix from what was discussed first.