Re: RT linker, rpath and security

[tlaronde%polynum.com@localhost]

Le Thu, May 11, 2023 at 09:45:07AM -0400, Greg Troxel a écrit :
> tlaronde%polynum.com@localhost writes:
> 
> > 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.
> 
> A common reason is to build against a pkgsrc version of a lib instead of
> base.
> 
> Obviously some things are contentious, but it strikes me that two things
> you could do that are unlikely to get significant objections:
> 
>   - implement a program that say finds every binary in PATH and checks
>     the RPATH entries, looking for some conditions you find unsafe and
>     just print out results.  Add this to pkgsrc so people can try it.
>     Actual data on unsafe configurations found in the world would inform
>     the discussion, and would help the paranoid patrol their systems.
> 

At first, putting aside efficiency, a sh(1) prototype should be easy,
using simply file(1) and readelf(1).

>   - Examine what pkgsrc is doing already.  I would not be surprised to
>     find that if a binary gets built with an RPATH outside of pkgsrc
>     (and not base X and base base) that this is an error, but maybe only
>     in developer mode.  This might also surface some interesting data.

I will give a look at the way pkgsrc does things. But as usual, there is
BSD make and then the GNU autoconf/automake dance and then the upstream
idiosynchrasies, so it is probably simpler to test the result than to
trace the compilation process (well, if there is a wrong result, one can
focus afterwards on the way this one is built).
-- 
        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