Bug 916727 - yum update from el6.3 to el6.4 causes wrong labeling of /sbin/ip6?tables-multi.*
Summary: yum update from el6.3 to el6.4 causes wrong labeling of /sbin/ip6?tables-multi.*
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: policycoreutils
Version: 6.4
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Michal Trunecka
URL:
Whiteboard:
: 916816 922281 (view as bug list)
Depends On:
Blocks: 947775 1018913
TreeView+ depends on / blocked
 
Reported: 2013-02-28 19:19 UTC by Tuomo Soini
Modified: 2014-09-30 23:34 UTC (History)
15 users (show)

Fixed In Version: policycoreutils-2.0.83-19.31.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1018913 (view as bug list)
Environment:
Last Closed: 2013-11-21 11:07:04 UTC
Target Upstream Version:


Attachments (Terms of Use)
work-around with iptables change (3.29 KB, patch)
2013-02-28 19:19 UTC, Tuomo Soini
no flags Details | Diff
/etc/selinux/targeted/contexts/files/file_contexts on RHEL-6.3 machine (248.84 KB, text/plain)
2013-03-01 12:56 UTC, Milos Malik
no flags Details
/etc/selinux/targeted/contexts/files/file_contexts on RHEL-6.3 machine updated to RHEL-6.4 (259.82 KB, text/plain)
2013-03-01 12:58 UTC, Milos Malik
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1608 normal SHIPPED_LIVE policycoreutils bug fix and enhancement update 2013-11-20 21:39:06 UTC

Description Tuomo Soini 2013-02-28 19:19:53 UTC
Created attachment 703935 [details]
work-around with iptables change

Description of problem:

yum update from el6.3 to el6.4 causes wrong labeling of /sbin/ip6?tables-multi.*

After upate files matched by the pattern are bin_t while they should be iptables_exec_t

restorecon does fix the issue

How reproducible:

Always.

Steps to Reproduce:

1. yum -y update
  
Actual results:

/sbin/iptables-multi-1.4.7 and /sbin/ip6tables-multi-1.4.7 both in bin_t selinux context.

Expected results:

iptables_exec_t

Additional info:

I generated to work-around patch to iptables to fix the issue but that's ugly as hell. Problem should be solved in selinux-policy - but because new policy is already out I guess fixing this requires full system relabeling.

But fixing the policy would help all new updates...

Comment 1 Daniel Walsh 2013-02-28 19:31:13 UTC
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.

Comment 3 Tuomo Soini 2013-02-28 21:55:35 UTC
With that patch applied to iptables package there i no output at all.

Without iptables restorecon patching there are iptables binaries in bin_t.

Comment 4 Daniel Walsh 2013-02-28 22:20:29 UTC
Fixed in /policycoreutils-2.1.14-11.el7

Comment 5 Tuomo Soini 2013-03-01 08:01:56 UTC
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

Comment 6 Tuomo Soini 2013-03-01 08:17:17 UTC
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

Comment 7 Milos Malik 2013-03-01 12:49:15 UTC
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
#

Comment 8 Milos Malik 2013-03-01 12:56:53 UTC
Created attachment 704153 [details]
/etc/selinux/targeted/contexts/files/file_contexts on RHEL-6.3 machine

Comment 9 Milos Malik 2013-03-01 12:58:06 UTC
Created attachment 704154 [details]
/etc/selinux/targeted/contexts/files/file_contexts on RHEL-6.3 machine updated to RHEL-6.4

Comment 10 Milos Malik 2013-03-01 13:03:03 UTC
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
#

Comment 11 Miroslav Grepl 2013-03-01 13:07:16 UTC
*** Bug 916816 has been marked as a duplicate of this bug. ***

Comment 12 Daniel Walsh 2013-03-01 14:39:01 UTC
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.

Comment 13 Levente Farkas 2013-03-01 21:28:45 UTC
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!

Comment 14 Daniel Walsh 2013-03-04 14:41:16 UTC
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.

Comment 15 Phil Anderson 2013-03-04 15:05:18 UTC
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.

Comment 16 Daniel Walsh 2013-03-04 17:02:28 UTC
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?

Comment 17 Phil Anderson 2013-03-05 01:20:58 UTC
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.

Comment 18 Daniel Walsh 2013-03-05 18:23:49 UTC
I agree it is a problem but don't really see an easy fix for it at this point.

Comment 20 cesarhv 2013-03-10 05:20:34 UTC
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.

Comment 21 Tuomo Soini 2013-03-11 14:21:44 UTC
cesarhv: there is very simple work-around for this problem.

run command:

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

Comment 22 Levente Farkas 2013-03-11 15:24:56 UTC
if it's so simple then why not create an update selinux package with this in the post install of the rpm???

Comment 23 Tuomo Soini 2013-03-11 15:43:37 UTC
Because the bug causing this is in policycoreutils.

Comment 24 Levente Farkas 2013-03-11 15:51:13 UTC
then an updated policycoreutils?:-)

Comment 25 Daniel Walsh 2013-03-11 18:19:41 UTC
We will.

Comment 26 cesarhv 2013-03-13 14:54:58 UTC
 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

Comment 27 Orion Poplawski 2013-03-16 02:32:27 UTC
*** Bug 922281 has been marked as a duplicate of this bug. ***

Comment 28 Erwan MAS 2013-05-17 14:47:13 UTC
I agree with  Phil Anderson , when i have upgraded my servers ,
I did not see immediately that fail2ban was not functional .

Comment 29 RHEL Product and Program Management 2013-06-12 12:41:51 UTC
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.

Comment 42 Miroslav Grepl 2013-10-14 14:38:41 UTC
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.

Comment 44 Michal Trunecka 2013-10-14 16:35:43 UTC
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++) {

Comment 49 errata-xmlrpc 2013-11-21 11:07:04 UTC
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

Comment 50 Tuomo Soini 2013-11-21 15:27:42 UTC
I don't see the fix for this in released version. Is this really fixed?

Comment 51 Daniel Walsh 2013-11-21 15:39:54 UTC
Not sure why there are private messages, but I made them public so people can see what we attempted to fix.

Comment 52 Tuomo Soini 2013-11-21 15:46:35 UTC
Ok. So there is totally different fix from what was discussed first.


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