| |||||||||||||
Tightening security: not for the impatientTightening security: not for the impatientPosted Jul 21, 2012 11:30 UTC (Sat) by anselm (subscriber, #2796)In reply to: Tightening security: not for the impatient by mathstuf Parent article: Tightening security: not for the impatient
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.
(Log in to post comments)
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).
|
|||||||||||||