Ubuntu 12.04 and symbolic links in world-writeable sticky-bitted directories
August 9, 2012
We're in the process of upgrading from Ubuntu 10.04 to Ubuntu 12.04,
and today we ran into a serious surprise. If you have a symlink in a
world writeable directory that has the sticky bit set so that only the
owner of a file can delete it (for example,
non-matching-uid symlink following attempted in sticky world-writable directory by cat (fsuid 915 != 2315) yama_inode_follow_link: 16 callbacks suppressed
(If you are testing this, note that the
This change has alleged security benefits (cf). It also caused an important part of our mail environment to explode, and it is not compatible with historical behavior (both for Linux and for Unix in general). Fortunately you can turn it off; in the Ubuntu 12.04 kernel you need to set /proc/sys/kernel/yama/protected_sticky_symlinks to 0 (instead of the default 1).
(This is also the sysctl
The history of this is somewhat tangled. The Linux kernel has a generic idea of 'security modules' (called LSMs) that are used to implement additional security policies over top of the standard Unix permissions; SELinux is the best known LSM, but there are others. In Ubuntu 12.04, Ubuntu has included their own 'Yama' LSM and used it to implement this restriction; a version of Yama that has this was proposed by Ubuntu's Kees Cook as far back as 2010 (also). The standard kernel code also has a (or the) Yama LSM, added at the end of 2011, but it lacks this restriction (and seems to never have had it).
(We only work with Ubuntu LTS releases, so I don't know if Yama and its restrictions appeared in any non-LTS releases between 10.04 (which definitely doesn't have it) and 12.04, or if it's genuinely new with 12.04.)
However, Kees Cook also proposed this restriction as a general patch at the end of 2011. A version of this
finally made it into the kernel on July 25th (after 3.5 was released but
before 3.6, so this restriction will be in 3.6 when it's released). The
actual restrictions are I believe only slightly different (the official
kernel code allows the symlink to be followed if it's owned by the
owner of the directory), but the important thing that the sysctl to
control it has changed. In the official kernel this is controlled by
(Credit where credit is due: a bunch of these links were found by one of my co-workers while I was busy doing less productive troubleshooting.)
I assume that Ubuntu will drop this restriction from their version of Yama and rely on the standard kernel code when they eventually do an Ubuntu release with a 3.6 or later kernel. At that point, anyone who is turning it off will need to change their sysctl. Hopefully we will remember all of this in a couple of years when the next Ubuntu LTS release happens and this becomes relevant to us again.
I am a grumpy Unix oldtimer and a sysadmin so my opinion on this change is very low. I found especially laughable the idea that Linux kernel people could confidently assert that there was no (legitimate) application that would be affected by this change. Congratulations, you blew up part of our mail system; I guess it doesn't exist.
(Our mail system works in such a way that I believe there are no security risks for us here, but justifying that will take an entire entry.)
Sidebar: another restriction, on hardlinking
Both the Ubuntu Yama LSM and the new standard kernel code for this stuff
include a second restriction, this time on what can be hardlinked. In
the standard kernel, this is controlled by
The Ubuntu Yama LSM has a similar sysctl in its
non-accessible hardlink creation was attempted by: ln (fsuid 2315)
Since I've just discovered this restriction, I don't know if we'll wind up turning it off on our 12.04 machines.
* * *
Atom feeds are available; see the bottom of most pages.