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

On Tue, Jul 28, 2026 at 3:17 AM Nick Clifton <[email protected]> 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.

> Cheers
>   Nick
>
>