re: hardlinks to setuid binaries

[matthew green <mrg%eterna.com.au@localhost>]

Joerg Sonnenberger writes:
> Am Fri, Mar 25, 2022 at 09:37:38AM -0400 schrieb Jan Schaumann:
> > Any thoughts on this?  Should there be a sysctl to
> > disable this?  This is not a new discovery; has this
> > been discussed before?
>
> The long standing recommendation is to separate user-writeable
> filesystems from system filesystems. It solves a number of different
> "attack" vectors at the same time. If root is going to create suid
> binaries in /tmp, they kind of asked for it to be abused.
>
> IMO nothing should be done here.

i think Taylor's suggestions about limiting based upon owner
and current user are good, and solve all potential issues,
without removing other useful features.

i don't see the benefit of a special mode/flag on a subdir to 
allow this.  as a normal user, i can create setuid to me and
i think that's a fine think to allow.  limiting this upon the
owner/current user solves all the issues i can imagine here.

i sure don't think any solution that requires separate /home
and / is useful.  too many systems don't install this way and
it limits the file system usage quite severely.  i've stopped
having separate of those on many of my systems beacuse the
size of netbsd grew so much my old guess as "/" was bad and
now i have a really annoying problem to solve.  for the ones
i really care about, my / is typically really excessively
sized to avoid this problem in the future, which is its own
waste of resources.  additionally, this doesn't help you in
a case of mis-configuration (oops! i left a write-able dir.)

forcing r/o for exec means you can't upgrade easily.  for
most users, that's not a reasonable solution.


(this said, many of Thor and your suggestions are good for a
specific hardened system that aren't expected to upgrade base
or pkgsrc often.  they're useful and valid ideas, in the right
place.)


.mrg.