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 1 of 2  [1] 2  Next page →

#197 — hardlinks to setuid binaries

Hello,

I just came across this blog post here:
https://rachelbythebay.com/w/2022/03/15/link/

In a nutshell, the author describes how being able to
create a hardlink to a setuid binary can lead to
undesirable results:

Suppose you have a setuid /usr/pkg/bin/sudo from sudo
version 1.8.11, which is vulnerable to CVE-2014-9680.
You create a hardlink in your home directory, so you
get setuid, owned by root, mode 511 '~/sudo'.

Now the sysadmin updates the sudo package, fixing the
vulnerability, but your ~/.sudo remains vulnerable.

On Linux, there appears to be a proc(5) restriction
via /proc/sys/fs/protected_hardlinks making this
impossible, but on NetBSD at least up to 9.2 this is
possible.

Any thoughts on this?  Should there be a sysctl to
disable this?  This is not a new discovery; has this
been discussed before?

-Jan

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

[toc] | [next] | [standalone]

#198

Jan Schaumann <jschauma@netmeister.org> wrote:
    > Suppose you have a setuid /usr/pkg/bin/sudo from sudo version 1.8.11,
    > which is vulnerable to CVE-2014-9680.  You create a hardlink in your
    > home directory, so you get setuid, owned by root, mode 511 '~/sudo'.

So, that would require that all pieces be on the same partition.

I would claim that /home should be mounted nosuid, and that it wasn't is
really the bug.

    > On Linux, there appears to be a proc(5) restriction via
    > /proc/sys/fs/protected_hardlinks making this impossible, but on NetBSD
    > at least up to 9.2 this is possible.

    > Any thoughts on this?  Should there be a sysctl to disable this?  This
    > is not a new discovery; has this been discussed before?



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

#199

On Fri, Mar 25, 2022 at 04:21:55PM +0100, Michael Richardson wrote:
> Jan Schaumann <jschauma@netmeister.org> wrote:
>     > Suppose you have a setuid /usr/pkg/bin/sudo from sudo version 1.8.11,
>     > which is vulnerable to CVE-2014-9680.  You create a hardlink in your
>     > home directory, so you get setuid, owned by root, mode 511 '~/sudo'.
> 
> So, that would require that all pieces be on the same partition.
> 

Well, hardlinks can only work within a single file system and/or mount
point to begin with..

	Jonathan

P.S
On some FSes you can't even hard link outside a single directory (AFS).

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

#200

On Fri, Mar 25, 2022 at 8:22 AM Michael Richardson <mcr@sandelman.ca> wrote:
>
> Jan Schaumann <jschauma@netmeister.org> wrote:
>     > Suppose you have a setuid /usr/pkg/bin/sudo from sudo version 1.8.11,
>     > which is vulnerable to CVE-2014-9680.  You create a hardlink in your
>     > home directory, so you get setuid, owned by root, mode 511 '~/sudo'.
>
> So, that would require that all pieces be on the same partition.
>
> I would claim that /home should be mounted nosuid, and that it wasn't is
> really the bug.

What a great observation! Around 2003, Debian root dev servers were
discovered compromised due to an old install, with vulnerable suid
binaries, mounted ro in a non-standard path, the old partitions were
retained as a bin, lib, etc backup. When the vulnerable binaries were
covertly exploited by a rogue developer, it was a mess for the OS.

I don't think it is necessary to mount user writable partitions nosuid,
that would be problematic for various suid/sgid sandbox directories.
Using separate partitions for the administrative suid binaries and
user writable directories covers all the cases I can imagine?

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

#201

Michael Richardson <mcr@sandelman.ca> wrote:
> Jan Schaumann <jschauma@netmeister.org> wrote:
>     > Suppose you have a setuid /usr/pkg/bin/sudo from sudo version 1.8.11,
>     > which is vulnerable to CVE-2014-9680.  You create a hardlink in your
>     > home directory, so you get setuid, owned by root, mode 511 '~/sudo'.
> 
> So, that would require that all pieces be on the same partition.
> 
> I would claim that /home should be mounted nosuid, and that it wasn't is
> really the bug.

Ok, so repeat the example on the same partition, say
/var/tmp (which, even if /tmp is more commonly now a
tmpfs, may not be).

I don't think demanding that all installs everywhere
have a 100% clean separation of setuid binaries from
user writable directories is a realistic solution.

FWIW, FreeBSD also seems to prohibit this; I haven't
checked OpenBSD.

-Jan

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

#202

    Date:        Fri, 25 Mar 2022 09:37:38 -0400
    From:        Jan Schaumann <jschauma@netmeister.org>
    Message-ID:  <20220325133738.GS1131@netmeister.org>

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

The link isn't the real problem, but like a lot of things, it is
easier to place blame where it doesn't belong rather than
accept it where it does.

kre


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

#203

> On Mar 25, 2022, at 3:42 PM, Robert Elz <kre@munnari.OZ.AU> wrote:
> 
> 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).

So, how do pax, tar, and rsync do this?  I expect they are the common means of updating that might lead to this situation, and therefore perhaps likely candidates for reducing the problem (if they do it in an undesired way).

Cheers,
Brook


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

#204

Robert Elz <kre@munnari.OZ.AU> 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.

In fact, what does pkgsrc do?

$ ls -ld
drwx------  2 jschauma  wheel  512 Mar 25 18:25 .
$ ls -l /usr/pkg/bin/screen-4.8.0 
-r-s--x--x  1 root  wheel  420272 Apr  4  2021 /usr/pkg/bin/screen-4.8.0
$ ln /usr/pkg/bin/screen-4.8.0
$ ls -l screen-4.8.0 
-r-s--x--x  2 root  wheel  420272 Apr  4  2021 screen-4.8.0
$ sudo pkg_delete screen
screen-4.8.0nb4: unregistering info file /usr/pkg/info/screen.info
screen-4.8.0nb4: removing /usr/pkg/bin/screen from /etc/shells
$ ls -l screen-4.8.0    
-r-s--x--x  1 root  wheel  420272 Apr  4  2021 screen-4.8.0
$

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".

-Jan

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

#205

> Date: Fri, 25 Mar 2022 18:29:15 -0400
> From: Jan Schaumann <jschauma@netmeister.org>
> 
> Robert Elz <kre@munnari.OZ.AU> 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?

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

#206

On Sat, 26 Mar 2022 at 12:00, Taylor R Campbell
<campbell+netbsd-tech-security@mumble.net> wrote:
>
> 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...)

If it's immediately prior to an unlink anyway that does seem like a
harmless enhancement.

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

Could do the hard links first, and the chmod u+s last :)

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

#207

On Fri, Mar 25, 2022 at 11:00:35PM +0000, Taylor R Campbell wrote:
> 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.

Instead of prohibitting those, we could require them to be done by the suid
owner or root.

Martin

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

#208

Martin Husemann wrote:

> On Fri, Mar 25, 2022 at 11:00:35PM +0000, Taylor R Campbell wrote:
> > 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.

That would break at/atq/artm/batch, chfn/chpass/chsh, passwd/yppasswd
and sysstat/systat in our base system.

> Instead of prohibitting those, we could require them to be done by the suid
> owner or root.

I tried to reproduce this and got EOPNOTSUPP when linked to a normal
or setuid binary that I didn't own.  Then it occurred to me that the
behaviour might be filesystem-specific.  I tested on ZFS originally. I
tried on FFS and was able to hard link to files I don't own, setuid or
not.

I agree with Martin - it makes sense to me to forbid hard linking to
files that you don't own.  Not sure if we can do this at the VFS later
or need to do it per filesystem?

Does POSIX/SUSvN/other-random-specs have anything to say about this?

Cheers,
Simon.

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

#212

On Sat, Mar 26, 2022 at 07:05:04 +0100, Martin Husemann wrote:

> On Fri, Mar 25, 2022 at 11:00:35PM +0000, Taylor R Campbell wrote:
> > 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.
> 
> Instead of prohibitting those, we could require them to be done by
> the suid owner or root.

I was about to suggest that too.

There's a binary blob somewhere in the filesystem and for that blob to
become a setuid binary it must be given 1) a name and 2) u+s bit.  The
normal chmod scenario has these ordered as 1-then-2, but the described
attack achieves the same result via 2-then-1 (where 2 was previously
done by the original owner in the 1-then-2 scenario).

I'd argue that 2-then-1 scenario should have the same restrictions as
1-then-2.

-uwe

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

#209

Here's some conditions we could apply to making hard links:

1. [zfs] Caller must own file.

2. [linux with protected_hardlinks] Either:
   (a) Caller must own file.
   (b) File must be regular and non-suid/sgid, and caller must have
       read&write access.

3. [least restrictive I could think of to prevent this attack] Either:
   (a) If suid, caller must own file.
   (b) If sgid, caller must be in group.

If we apply conditions, I think we should apply them uniformly across
file systems.

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

#210

On Sun, 27 Mar 2022 at 00:19, Taylor R Campbell
<campbell+netbsd-tech-security@mumble.net> wrote:
>
> Here's some conditions we could apply to making hard links:
>
> 1. [zfs] Caller must own file.
>
> 2. [linux with protected_hardlinks] Either:
>    (a) Caller must own file.
>    (b) File must be regular and non-suid/sgid, and caller must have
>        read&write access.
>
> 3. [least restrictive I could think of to prevent this attack] Either:
>    (a) If suid, caller must own file.
>    (b) If sgid, caller must be in group.
>
> If we apply conditions, I think we should apply them uniformly across
> file systems.

The Linux way is really annoying when wanting to create a link farm of
files that by design shouldn't be writable.  I find myself turning the
entire control off, which in turn means the security advantage
vanishes.

I like #3 for that reason, because being able to link to a non-setuid
file is a useful thing.

I think 3b makes sense, but I could also imagine maybe owning the file
as the condition for both setgid and setuid could also make sense.

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

#211

Taylor R Campbell <campbell+netbsd-tech-security@mumble.net> wrote:
> Here's some conditions we could apply to making hard links:

> 3. [least restrictive I could think of to prevent this attack] Either:
>    (a) If suid, caller must own file.
>    (b) If sgid, caller must be in group.

Yeah, I think this is what I'd have in mind.  Possibly
guarded with a sysctl and tied to securelevel.

FreeBSD has security.bsd.hardlink_check_[ug]id:
https://lists.freebsd.org/pipermail/freebsd-security/2004-March/001703.html

So we could:

- by default, set security.bsd.hardlink_check_[u]gid = 1
  with the same semantics as in FreeBSD
- in securelevel = 2 (1?),
  security.bsd.hardlink_check_[ug]id cannot be changed

> If we apply conditions, I think we should apply them uniformly across
> file systems.

Yes, agreed.

-Jan

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

#213

On Sat, Mar 26, 2022 at 11:19:22AM +0000, Taylor R Campbell wrote:
> 
> 3. [least restrictive I could think of to prevent this attack] Either:
>    (a) If suid, caller must own file.
>    (b) If sgid, caller must be in group.

I believe, based on some past experience with this along the way to the
conclusion that, practically, my device runtime simply needed to have
multiple filesystems and enforce W^X through the expedient of mounting
all writable filesystems noexec, that  you may want to enforce the
owner/group condition on hard links to device nodes as well.

If we could enforce restrictions on filesystem subtrees, generally,
it would be possible to enforce nosuid on link targets writable by non-root
users, and call it a day.  But really, "is cwd below directory 'D'" is not
an easy thing to do in our kernel, more's the shame.

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?

Thor

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

#214

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.

Joerg

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

#216

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

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

#218

On Mon, Mar 28, 2022 at 1:35 PM David Holland
<dholland-security@netbsd.org> wrote:
> 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)

For simplified storage management, I typically put home in a /usr
partition and symlink it from the root partition, and allocate typical
/tmp and /var partitions, separate from root. That obviously exposes
me to the potential of user hardlinked vulnerable suid binaries.

For all of the solutions discussed the consequences don't seem
to outway administratively separating user writable partitions, ie
(my) practice change but no implementation change.

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?

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web