| |||||||||||||
Tightening security: not for the impatientTightening security: not for the impatientPosted Jul 3, 2012 22:01 UTC (Tue) by ScottMinster (subscriber, #67541)Parent article: Tightening security: not for the impatient
a hard link to a file can only be created if the user owns the file or has write access to it This doesn't sound too good. Where I work, we have applications that regularly create hard links to files just for reading. The reason we do this is in case the file is replaced by a new version while it is being read. This shouldn't be a problem on most file systems, but NFS has given us trouble in the past, and we're often using NFS filesystems. The code follows the pattern of link(), open(), and unlink(). The NFS server will keep the unlink'ed file, and more importantly the NFS key (or whatever its called) around so the original file's contents can be read, even if the file is replaced with a new version (through writing to a temporary file and renaming). While the code is robust enough to fallback on opening the original file instead of a temporary link if it cannot make the link (often happens if the directory itself is not writable), it would be annoying to lose this feature. We've had weird race conditions in the past on NFS without this logic. 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.
(Log in to post comments)
Tightening security: not for the impatient Posted Jul 11, 2012 21:30 UTC (Wed) by BenHutchings (subscriber, #37955) [Link] 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.
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).
|
|||||||||||||