SGID/SUID on scripts

[perryh at pluto.rain.com]

Ivan Voras <ivoras at freebsd.org> wrote:
> 2009/7/23  <perryh at pluto.rain.com>:
> > Ivan Voras <ivoras at freebsd.org> wrote:
> >> Presumingly, the biggest concern is with scripts owned by root.
> >> Who can unlink, move or change the script? The owner and his
> >> group can change it; the directory owner can unlink it ...
> >
> > Anyone can make a link to such a script in, say, /tmp and then
> > mess with the link :(
>
> You mean setuid a soft link? That's allowed?

One can certainly make a symlink that points to a setuid file.
The permissions of the symlink itself don't matter.

IIRC the original demonstration that this exposure was real and not
just theoretical involved making -- and subsequently messing with
-- a hard link in /tmp to a setuid script in /bin, /tmp and /bin
both being on the root FS.  (This was before machines commonly had
enough RAM for tmpfs to be practical, and may have been before
symlinks even existed.)  Granted a case can be made for making /tmp
a separate FS in any event, but of course it would have worked just
as well to make a link in /usr/tmp to a setuid script in /usr/bin,
etc.  The only way to avoid the exposure would have been to ensure
that no possible attacker would have write permission to any
directory on the same FS as a setuid script to which the attacker
had execute permission -- not the easiest thing to keep track of on
an ongoing basis.  With the existence of symlinks I suspect even
that would no longer help.