Re: RT linker, rpath and security

[tlaronde%polynum.com@localhost]

Le Fri, May 12, 2023 at 03:37:57PM +1200, Lloyd Parkes a écrit :
> 
> 
> On 12/05/23 07:43, tlaronde%polynum.com@localhost 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.

There is another difference to take into account: sysutils (utils that
could be used as root) and others.

root or toor have a PATH limited to NetBSD provided utilities, for me
and for the majority I think. Their shell is sh(1) or ksh(1) for some
sugar, but still provided by NetBSD. But there are some utilities, found
in pkgsrc, that can be used in a root context. They are more problematic
and require probably more scrutiny.

> 
> 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 have started to look for an utility. The problem, is that with
dynshared, an executable can extend its functionnalities, and can start
loading extensions that are elsewhere (a lot of complex third parties
programs have subdirs in /usr/pkg/lib, /usr/pkg/libexec and so on). So
the dynshared feature is a way to escape "paths" and PATH...

ELF dynshared Libraries have also their rpath. And if you add that
scripts in PATH can reach whatever they want, you end up trying to
locate every ELF file in the filesystem to verify...

The best solution is a hook in execve and the RT linker, the way you let
a program function and trap when it tries to "go further" the limit.

Post-checking the system will never be full bullet proof. Checking
extensively when building a package is possible (because of the limited
amount of files to check) and then trusting these incremental checks
(checking what has been modified since last check).

But the best solution is at the core, IMHO.
-- 
        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