Re: hardlinks to setuid binaries

[Steffen Nurpmeso <steffen%sdaoden.eu@localhost>]

George Georgalis wrote in
 <CAHK3FNxCj4o1UqwrVODP33cynWTo247AfOQf9mwLHN0e+mg_6w%mail.gmail.com@localhost>:
 |On Thu, Mar 31, 2022 at 10:09 AM Steffen Nurpmeso <steffen%sdaoden.eu@localhost> \
 |wrote:
 |> Michael Richardson wrote in
 |>  <19821.1648745882@localhost>:
 |>|George Georgalis <george%galis.org@localhost> wrote:
 |>|> However, an audit of package hardlink count, warning on check,
 |>|> block on upgrade (without --force), to facilitate finding extra links,
 |>|> seems like a low cost sanity check?
 |>|
 |>|It sure seems like it's the upgrade process that needs to care to remove
 |>|"old" suid bits on old executables.  Or alternatively, overwrite them \
 |>|without
 |>|changing the inode.  It's a tussle as to which is better.
 |>
 |> Yes exactly.  Drop the stuff, then atomic rename.  What else
 |> can it be to not have problems after the atomic rename.
 |
 |While reporting unexpected link count in package check
 |or upgrade is informative, altering the mode or data of
 |extra links may be a bit heavy handed. While the data
 |would be on the same filesystem, it was certainly not
 |part of the OS install and in cases with legitimate use
 |of hardlinks, altering the target would certainly not
 |be expected, and could cause problems at the site.
 |
 |For example, imagine a scientific HPC site with the
 |requirement of being able to reproduce computational
 |runs. An administrator maintains the compute OS and
 |packages, Prior to a client data run, a novel prefix is
 |created for nfs export of hardlinked OS files and site
 |software. Then the job is executed and the prefix
 |is retained for runs with alternate parameters or
 |corrected data. Simultaneously, another prefix is
 |created for another project. In this scenario, multiple
 |scientific staff could easily be submitting multiple
 |jobs, while multiple prefixes are maintained by multiple
 |quality people. While this all progresses swimmingly
 |an administrator updates the reference OS and packages
 |only to find all the links in per client prefix have been
 |overwritten?

Now wait a bit.  I said on Linux i have

  protected_fifos
  protected_hardlinks
  protected_regular
  protected_symlinks

enabled as per

  usr/src/linux/Documentation/admin-guide/sysctl/fs.rst

If the kernel does not help, then maybe

  https://marc.info/?l=netbsd-tech-security&m=164824457428337&w=2

is not a bad idea?  And please note the follow-up (ie it has to be
done -- but i am sorry if you feel i disturbed a nice
crackerbarrel conversation).

 |The administrator could copy the reference OS to an
 |alternate root vs the one being maintained, to prevent
 |linked binaries from being changed by OS upgrades,
 |but my position is sanitizing the files (links) outside of
 |the expected OS path is not expected behavior at all.

Lucky me i am not an administrator.
Btw the FreeBSD ZFS way to snapshot, use bhyve to start into that
snapshot, upgrade, then reboot into that snapshot easily is cool.
(It does not help with this problem, but i would bet you use
a different mount point for / and /home if you do; i for example
have mirrored that a little bit with BTRFS, subvol=/crux/kent/root
is /, and i replace snapshot root.old with root before i start the
system upgrade.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)