| |||||||||||||
Tightening security: not for the impatientTightening security: not for the impatientPosted Jul 11, 2012 21:30 UTC (Wed) by BenHutchings (subscriber, #37955)In reply to: Tightening security: not for the impatient by ScottMinster Parent article: Tightening security: not for the impatient
Perhaps link() should be allowed to work if the user has read or write access to the file? Making a hard link to a file that cannot be read by the current user does seem to have little purpose. If a setuid executable turns out to be exploitable, the sysadmin will (hopefully) upgrade it to a fixed version quickly. But in some filesystem configurations a malicious user could use hard links to make 'backups' of setuid executables in the expectation that one of them would later turn out to be exploitable. The hard link restrictions prevent this.
(Log in to post comments)
Tightening security: not for the impatient Posted Jul 11, 2012 22:44 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
> ... in some filesystem configurations a malicious user could use hard links to make 'backups' of setuid executables in the expectation that one of them would later turn out to be exploitable.
Some other reasonable workarounds for this issue would be to clear the setuid bit before replacing a setuid executable, to restrict setuid executables to a dedicated filesystem with no non-superuser write access, or to prevent creating links to files with setuid enabled.
Or we could drop setuid entirely and go with something more like PolicyKit, which isn't affected by hard links, thus making the root -> user transition a one-way street.
Tightening security: not for the impatient Posted Jul 12, 2012 11:06 UTC (Thu) by philomath (guest, #84172) [Link]
Disabling links to suid files seems very reasonable, and will most probably break nothing sane.
Tightening security: not for the impatient Posted Jul 17, 2012 9:29 UTC (Tue) by nlucas (subscriber, #33793) [Link]
It might break current busybox installations. Multiple suid binaries are linked to the same binary.
But I agree with you that it's a reasonable breakage.
Tightening security: not for the impatient Posted Jul 17, 2012 15:18 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
That should still work, so long as you create the links _before_ marking the binary as SUID. You could look at the reference count to ensure that there are no "rogue" links at that point. Once it's marked SUID, no new hard links could be created without first clearing the SUID bit.
Tightening security: not for the impatient Posted Jul 20, 2012 23:41 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
I seem to have run across the problem that hardlinked files all shared the same permissions. Are the tests we ran for that missing something or is it just suid that is special?
Tightening security: not for the impatient Posted Jul 21, 2012 11:30 UTC (Sat) by anselm (subscriber, #2796) [Link] Hard-linked files do share the same permissions – permissions are stored on the file's inode and hard links are just extra directory entries that point to the same inode. Linux will not let you create a hard link to an executable file that is marked suid but doesn't belong to you. Making hard links to a file that you own yourself is fine regardless of whether that file is suid or not, and does not impinge on the suid status of the file.
Tightening security: not for the impatient Posted Jul 21, 2012 16:55 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
Okay, so why make the binary SUID after hardlinking? Since that makes *every* one of those binaries SUID now. If it's something like toybox, I don't want sed to be SUID even if mount is hardlinked to it. Seems like there's a case for having a separate SUID instance that those programs link to.
Tightening security: not for the impatient Posted Jul 23, 2012 13:15 UTC (Mon) by nlucas (subscriber, #33793) [Link]
The busybox project is well is aware of that and recomends a different busybox binary for suid and regular binaries.
It's easy enough to build a busybox binary implementing only the suid utils (as is to not include the suid utils on the regular binary).
|
|||||||||||||