Re: RT linker, rpath and security

[email protected] 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.

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