RFC: Should the linker warn about and/or control the propagation of audit libraries ?

[Matt Rice]

On Tue, Jul 28, 2026 at 4:03 AM Matt Rice <ratmice@gmail.com> wrote:
>
> On Tue, Jul 28, 2026 at 3:17 AM Nick Clifton <nickc@redhat.com> wrote:
> >
> > Hi Guys,
> >
> >   I am using an AI tool to look for potential security issues in the
> >   binutils sources.  (Note - I am not using the tool to fix any
> >   problems, just report them).  It has raised an interesting issue:
> >
> >     The linker automatically reads DT_AUDIT entries from all
> >     input shared libraries and adds them as DT_DEPAUDIT entries
> >     in the output binary, with no warning.  DT_DEPAUDIT causes
> >     ld.so to load the named audit library at runtime, which can
> >     intercept all symbol resolutions via the rtld-audit interface
> >     (la_symbind, la_pltenter, etc.).
> >
> >     A malicious shared library provided as a dependency (e.g.,
> >     through a compromised package repository) can cause all
> >     binaries linked against it to automatically load an attacker
> >     controlled audit library at runtime, without any special
> >     linker flags and with no diagnostic output.  The user never
> >     requested this — it is silently introduced in the output.
> >
> >   I am wonder what, if anything, we should do about this.  The obvious
> >   thing to do would be to add a new command line option, something like:
> >
> >     --audit-library-propogation=[default|silent|warn|refuse]
> >
> >   which would either silently propagate the libraries (ie the current
> >   behaviour) or copy them, but also issue a warning message when it does
> >   so, or refuse to copy them and issue error messages instead.  The
> >   default behaviour could also be controlled by a configure time option.
> >
> >   Is this going too far ?  Would it even be helpful ?  What do you think.
> >
>
> I know I've had patches to ld.so which implement this behavior, and used it in
> system-wide audit libraries to emulate the mac os ".framework" style
> relative linking
> on systems like mac os. However my question is *which* libc's support
> loading DT_AUDIT and DT_DEP_AUDIT from ld.so without changes?
>
> I was never brave enough to submit patches to this for glibc although
> I implemented
> them and used them for a long time. The only other rtld besides my patched one
> that I know of which implements this and actually exists in the wild
> beyond solaris derived ones.
> Which I don't think by default uses a gnu-ld?
>
> Perhaps though someone implemented the glibc ld.so parts when I wasn't
> paying attention?
> Otherwise, I'd be pretty surprised if this is actually relevant to
> more than a few people.
>

sorry I do see now it was added in glibc 2.32

> > Cheers
> >   Nick
> >
> >