Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > muc.lists.netbsd.tech.security > #197 > unrolled thread

hardlinks to setuid binaries

Back to article view | Back to muc.lists.netbsd.tech.security

Contents

  hardlinks to setuid binaries Jan Schaumann <jschauma@netmeister.org> - 2022-03-25 09:37 -0400
    Re: hardlinks to setuid binaries Michael Richardson <mcr@sandelman.ca> - 2022-03-25 16:21 +0100
      Re: hardlinks to setuid binaries "Jonathan A. Kollasch" <jakllsch@kollasch.net> - 2022-03-25 11:12 -0500
      Re: hardlinks to setuid binaries George Georgalis <george@galis.org> - 2022-03-25 10:06 -0700
    Re: hardlinks to setuid binaries Jan Schaumann <jschauma@netmeister.org> - 2022-03-25 17:34 -0400
    Re: hardlinks to setuid binaries Robert Elz <kre@munnari.OZ.AU> - 2022-03-26 04:42 +0700
      Re: hardlinks to setuid binaries Brook Milligan <brook@nmsu.edu> - 2022-03-25 15:51 -0600
      Re: hardlinks to setuid binaries Jan Schaumann <jschauma@netmeister.org> - 2022-03-25 18:29 -0400
        Re: hardlinks to setuid binaries Taylor R Campbell <campbell+netbsd-tech-security@mumble.net> - 2022-03-25 23:00 +0000
          Re: hardlinks to setuid binaries David Sainty <david.sainty@gmail.com> - 2022-03-26 18:58 +1300
          Re: hardlinks to setuid binaries Martin Husemann <martin@duskware.de> - 2022-03-26 07:05 +0100
            Re: hardlinks to setuid binaries Simon Burge <simonb@NetBSD.org> - 2022-03-26 17:17 +1100
            Re: hardlinks to setuid binaries Valery Ushakov <uwe@stderr.spb.ru> - 2022-03-26 17:47 +0300
    Re: hardlinks to setuid binaries Taylor R Campbell <campbell+netbsd-tech-security@mumble.net> - 2022-03-26 11:19 +0000
    Re: hardlinks to setuid binaries David Sainty <david.sainty@gmail.com> - 2022-03-27 00:45 +1300
    Re: hardlinks to setuid binaries Jan Schaumann <jschauma@netmeister.org> - 2022-03-26 11:52 -0400
    Re: hardlinks to setuid binaries Thor Lancelot Simon <tls@panix.com> - 2022-03-27 13:47 -0400
    Re: hardlinks to setuid binaries Joerg Sonnenberger <joerg@bec.de> - 2022-03-27 22:08 +0200
      re: hardlinks to setuid binaries matthew green <mrg@eterna.com.au> - 2022-03-28 23:42 +1100
        Re: hardlinks to setuid binaries George Georgalis <george@galis.org> - 2022-03-30 18:00 -0700
          Re: hardlinks to setuid binaries Michael Richardson <mcr@sandelman.ca> - 2022-03-31 12:58 -0400
            Re: hardlinks to setuid binaries Steffen Nurpmeso <steffen@sdaoden.eu> - 2022-03-31 19:09 +0200
              Re: hardlinks to setuid binaries George Georgalis <george@galis.org> - 2022-04-01 15:37 -0700
                Re: hardlinks to setuid binaries Steffen Nurpmeso <steffen@sdaoden.eu> - 2022-04-02 01:21 +0200
      Re: hardlinks to setuid binaries David Holland <dholland-security@netbsd.org> - 2022-03-28 20:35 +0000
    Re: hardlinks to setuid binaries David Holland <dholland-security@netbsd.org> - 2022-03-27 23:22 +0000

Page 2 of 2 — ← Prev page 1 [2]

#219

[Multipart message — attachments visible in raw view] — view raw

George Georgalis <george@galis.org> 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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

[toc] | [prev] | [next] | [standalone]

#220

Michael Richardson wrote in
 <19821.1648745882@localhost>:
 |
 |George Georgalis <george@galis.org> 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.
Just to mention i have

  #?0|kent:~# sysctl fs.protected_regular fs.protected_fifos fs.protected_hardlinks fs.protected_symlinks
  fs.protected_regular = 2
  fs.protected_fifos = 2
  fs.protected_hardlinks = 1
  fs.protected_symlinks = 1

--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)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

[toc] | [prev] | [next] | [standalone]

#221

On Thu, Mar 31, 2022 at 10:09 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
>
> Michael Richardson wrote in
>  <19821.1648745882@localhost>:
>  |
>  |George Georgalis <george@galis.org> 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?

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.

-George

-- 
George Georgalis, (415) 894-2710, http://www.galis.org/

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

[toc] | [prev] | [next] | [standalone]

#222

George Georgalis wrote in
 <CAHK3FNxCj4o1UqwrVODP33cynWTo247AfOQf9mwLHN0e+mg_6w@mail.gmail.com>:
 |On Thu, Mar 31, 2022 at 10:09 AM Steffen Nurpmeso <steffen@sdaoden.eu> \
 |wrote:
 |> Michael Richardson wrote in
 |>  <19821.1648745882@localhost>:
 |>|George Georgalis <george@galis.org> 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)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

[toc] | [prev] | [next] | [standalone]

#217

On Mon, Mar 28, 2022 at 11:42:31PM +1100, matthew green wrote:
 > 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.

You could imagine two flags, one for root and one settable by users
that allows a directory to contain objects setuid to the directory
owner or setgid to the directory group. (like the two immutable flags)

It's more obviously useful for device nodes, since the only times when
device nodes belong anywhere except /dev (and a chroot tree's /dev)
are very specific arrangements established explicitly by the sysadmin.

Plenty of compat issues to figure out before trying to deploy either,
though.

(though I don't see where even the setuid flag interferes with
updating base and in pkgsrc it'll only interfere with the small number
of packages that build in destdir but not user-destdir mode)

-- 
David A. Holland
dholland@netbsd.org

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

[toc] | [prev] | [next] | [standalone]

#215

On Sun, Mar 27, 2022 at 01:47:44PM -0400, Thor Lancelot Simon wrote:
 > Even better, imagine requiring an attribute to be set on a directory
 > in order to _allow_ it to contain setuid executables.  Or device nodes.
 > Wouldn't that, in general, be safer and better than trying to decide all
 > the places where such things should _not_ be allowed?

That is a good idea...

-- 
David A. Holland
dholland@netbsd.org

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | muc.lists.netbsd.tech.security

csiph-web