pgfdp@nzapmb.co.nz (Paul Fox ) (12/03/88)
This topic started in the new.admin groups or somewhere, and it was explained why chrooting needs to be restricted to root, even though chroot seems on first blush to result in a restriction of privelege, not an expansion of privelege. Can someone tell me -- if the problems of chroot'ing are due to being able to ln an suid'ed file (e.g. "ln /bin/su /tmp; chroot /tmp ..."), and if the problems of set-uid shell scripts are due to being able to ln to an suid'ed script, could it be that we could kill several birds with one stone by preventing hard links to files with the suid bit set, and conversely not setting the bit on files with multiple links? Of course, I suppose it would be safe for the owner of an suid file to link to it. For symlinks, of course, the permission checking would need to be done when the link is followed, since you can't follow symlinks backwards when the "chmod u+s" is done. Perhaps the suid bit could be ignored if the inode was reached via symlink? What would be the cost of this inelegance? Are multiple links to suid files necessary? Would this sort of change be crushed by backwards incompatibility? ------------ paul fox, currently reachable as pgfdp@apmpyr.nzapmb.co.nz
rcd@ico.ISC.COM (Dick Dunn) (12/09/88)
In article <162@apmpyr.nzapmb.co.nz>, pgfdp@nzapmb.co.nz (Paul Fox ) writes: . . . > Can someone tell me -- if the problems of chroot'ing are due to being > able to ln an suid'ed file (e.g. "ln /bin/su /tmp; chroot /tmp ..."), > and if the problems of set-uid shell scripts are due to being able to > ln to an suid'ed script, could it be that we could kill several birds > with one stone by preventing hard links to files with the suid bit set, > and conversely not setting the bit on files with multiple links?... But no, the problems of chroot are more than just ln to setuid files, and similarly with setuid shell scripts. Moreover, the suggested change (prevent hard links to setuid files) introduces a significant restriction to things we can do now, in order to allow something which *might* be useful (unre- stricted chroot) that we can't do now. It is fairly common to have multiple links to a file with different names, such that the program figures out what it's supposed to do based on its name. It seems unnatural to prohibit this for setuid programs, particularly since they might have significant "validation" code which can be shared among multiple tasks. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...I'm not cynical - just experienced.