Re: hardlinks to setuid binaries

[Taylor R Campbell <campbell+netbsd-tech-security%mumble.net@localhost>]

> Date: Fri, 25 Mar 2022 18:29:15 -0400
> From: Jan Schaumann <jschauma%netmeister.org@localhost>
> 
> Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
>  
> >   | Now the sysadmin updates the sudo package, fixing the
> >   | vulnerability, but your ~/.sudo remains vulnerable.
> > 
> > It depends how the update is done.   unlink old, install new,
> > will have that effect, but chmod 0 old, unlink old, install
> > new does not, nor does cp new old (in all cases, with
> > needed chown, chmod, etc, done after the binary update as well).
> 
> I don't think I've seen a whole lot of updates perform
> these steps, and would guess that the overwhelming
> majority of systems or package managers simply unlink.

tar and rsync both write to a temporary file and then rename it to the
permanent pathname, so upgrades done with them are vulnerable to this
kind of downgrade-suid attack.

> I'm not arguing that there aren't many other ways
> people can prevent the problem from arising.  I'm
> saying that few people will use these ways, and it
> might be worth considering helping those who don't
> rather than say "too bad, you're doing it wrong".

I agree.

If I understand correctly, the problem is that these methods of update
don't revoke suid power (or sgid power) of the file when we realize
it's dangerous -- and simply replacing the link isn't enough to revoke
the file's suid power.

Maybe pkg_delete, and any tool to update base, should clear the
suid/sgid bits first?  (Of course, if you clear the suid/sgid bit on
/usr/bin/su and something goes wrong with the update, you might be in
bad shape...)

A heavier hammer, not requiring changes to pkg_delete or anything,
would be to prohibit creating hard links to files with suid/sgid bits,
and to prohibit setting the suid/sgid bits on files with >1 link.  But
we'd have to think through the consequences -- e.g., that would rule
out having a /rescue/su built with crunchgen like the rest of rescue
(but that's not something we do at the moment anyway).  What else
might rely on multiple links to a suid/sgid file?