Feature changed by: Stefan Knorr (stfnknorr) Feature #316562, revision 15 Title: Add fs.protected_hardlinks=1 Requested by: Sebastian Krahmer (krahmer) Partner organization: openSUSE.org Description: In order to disallow hard linking to suid files etc we should enable hardlink protection: fs.protected_hardlinks=1 or via apropriate /proc entry. Relations: - enable hardlink and symlink protection (novell/bugzilla/id: 821585) https://bugzilla.novell.com/show_bug.cgi?id=821585 Discussion: #1: Marcus Meissner (msmeissn) (2013-09-30 15:54:21) is already in factory, so will be in sle12 hopefully #2: Anja Stock (neyleah) (2015-03-03 11:29:14) (reply to #1) Marcus, can you please be so kind as to provide me with a more current status? #3: Marcus Meissner (msmeissn) (2015-03-03 17:52:41) (reply to #2) The feature can be considered done. - Release Notes: Enable hardlink protection + Release Notes: Protection of Hard Links and Symbolic Links Enabled by + Default Challenge: - A long-standing class of security issues are both softlink- and - hardlink-based time-of-check-time-of-use race, most commonly seen in - world-writable directories like /tmp. The common method of exploitation - of this flaw is to cross privilege boundaries when following a given - softlink or hardlink (i.e. a root process follows a hardlink created by - another user). Additionally, on systems without separated partitions, - unauthorized users could "pin" vulnerable setuid/setgid files against - being upgraded by the administrator by hardlinking them, or linking to + A long-standing class of security issues are time-of-check/time-of-use + races of symbolic links and hard links, most commonly seen in world- + writable directories like /tmp . The common method of exploitation of + this flaw is to cross privilege boundaries when following a given + symbolic link or hard link. That is, having a root process follow a + link created by another user. + Additionally, on systems without separated partitions, unauthorized + users could "pin" vulnerable setuid/setgid files against being upgraded + by the administrator by creating hard links to them or linking to special files. Solution: - In /usr/lib/sysctl.d/50-default.conf , this behavior can be set: - * When set to "0", symlink following behavior is unrestricted. - * When set to "1" symlinks are permitted to be followed only when - outside a sticky world-writable directory, or when the uid of the - symlink and follower match, or when the directory owner matches the - symlink's owner. - SUSE now sets this to "1" by default. + In /usr/lib/sysctl.d/50-default.conf , this behavior can now be + adjusted using the options fs.protected_hardlinks and fs. + protected_symlinks : + * When set to 0 , links can be followed unrestrictedly. + * When set to 1 , links are permitted to be followed only when outside + a sticky world-writable directory matches, or when the uid of the link + and follower match, or when the directory owner matches the link's + owner. + SUSE now sets this to 1 by default. -- openSUSE Feature: https://features.opensuse.org/316562