Re: RT linker, rpath and security

Am Fri, May 12, 2023 at 03:37:57PM +1200 schrieb Lloyd Parkes:
> 
> 
> On 12/05/23 07:43, [email protected] wrote:
> > Le Thu, May 11, 2023 at 09:45:07AM -0400, Greg Troxel a écrit :
> > ...
> > 
> > $ readelf -d /usr/pkg/sbin/visudo | egrep "NEEDED|RPATH"
> > 
> >   0x0000000000000001 (NEEDED)             Shared library: [libc.so.12]
> >   0x000000000000000f (RPATH)              Library rpath: [/usr/pkg/lib]
> > 
> > visudo depends only on the system libc (I'm on NetBSD 9.3) and
> > loads the dynshared /usr/pkg/libexec/sudo_noexec.so (the full path is
> > given) but still there is a rpath registered pointing to /usr/pkg/lib.
> > 
> > If a package would be installing a libc.so.12 under /usr/pkg/lib, this
> > one will be used instead of the system one.
> 
> I can see two issues here:
> 
> 1) Some pkgsrc binaries are installed with /usr/pkg/lib in their rpath when
> they don't need it. I'm going to guess that pkgsrc always puts /usr/pkg/lib
> on every binary's rpath. Allowing packages to opt out of this behaviour for
> individual binaries should be possible, but I don't think it's worth the
> trouble.

No, it doesn't. But when you deal with packages that may or may not be
system libraries, it is easier to just add it.

> 2) Packages can shadow shared libraries in /usr/lib. (Assuming the library
> rpath has priority over /usr/lib, it probably does but I haven't checked.)
> We already check the PLIST of packages that are about to be installed for
> files that will conflict with ones that are already installed. We could
> enhance this to check for shadowing of shared libraries in /usr/lib and then
> issue an error or a warning.

I don't see the point as this happens intentionally often enough.
Consider Linux systems without development packages installed, where you
often end up with libz or so installed from pkgsrc.

Joerg