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


Groups > muc.lists.netbsd.tech.security > #216

re: hardlinks to setuid binaries

From matthew green <mrg@eterna.com.au>
Newsgroups muc.lists.netbsd.tech.security
Subject re: hardlinks to setuid binaries
Date 2022-03-28 23:42 +1100
Organization Newsgate at muc.de e.V.
Message-ID <4455.1648471351@splode.eterna.com.au> (permalink)
References <YkDENW2pDkWu7i8V@bec.de>

Show all headers | View raw


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.

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

Back to muc.lists.netbsd.tech.security | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

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

csiph-web