Re: RT linker, rpath and security

[tlaronde%polynum.com@localhost]

Le Thu, May 11, 2023 at 07:45:39AM -0400, Mouse a écrit :
> >>> Isn't it the way a run time linker uses rpath search path a
> >>> security risk?
> 
> Welcome to one reason I don't install binaries someone else built.
> 
> Question, though: how is this different from trusting that the
> program's own code itself does nothing malicious (whether accidentally
> or deliberately)?

The problem is precisely safety (for me, safety includes not only
deliberate faults [security] but accidental faults: blunders, uninformed
choices etc. And I tend to think that the latter are far numerous than
the former).

NetBSD provides paxctl(8) for security(7) reasons.

Why the argument "admin should know better" isn't given for these
instead of implementing security measures?

We can not compare PATH, one and only one known explicit series of
paths with as many as executables hidden series of paths.

Why not consider, if we drop the root owned or other writable
directories conditions, having as "safety" measure, a ELF_RPATH
env variable, that defaults to "/usr/lib:/lib" and that is a mask
against an ELF rpath: a path in rpath is only searched if it exists
in ELF_RPATH (perhaps even searched in the order specified by
ELF_RPATH).

All in all, with dynamically shared executables, if executables are
searched with a PATH, masking some, extensions (dyn shared) should be
searched according to a ELF_RPATH.

If every executable has to be trusted, why paxctl(8)? Because it
is more noble if malicious code is embedded deep and implies
acrobatics? NetBSD protects against difficult exploits but not
against easy ones, painful needles that can go unseen because they are
lost in the hay stack of hours of compilation: "Admin should know
better"?

And I fail to see why a constant rule should not be for the RT
linker to search first for /usr/lib:/lib, that is to forbid to mask
system libraries (perhaps a paxctl(8) feature) before resorting to
rpath or other means to set a series of paths to search. The only
possible scenario I can find for the need of masking system libraries
is someone having an executable and not the source code, unable to
relink it, while a dynamically shared library specified in the
executable matches a system one that does not work with the crucial
executable. But if there are rules this is precisely to allow explicit
exceptions.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C