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 didn't really comment in my previous message about the command line option,
In my case where I had basically a system audit library which made linking work
for anything using framework style linking via adding an la_objsearch
that worked
with relative paths, it would have been pretty annoying to see warnings.

I would have leaned towards some way to selectively disable it for
known libraries
like `--allow-audit-library-propagation=/path/to/libfoobar-audit` or
even `-lfoobar-audit`?
while still not disabling the warning entirely. Anyhow I'm pretty
skeptical of boolean on/off
switches, and would lean towards selectively disabling it for a
specific context.

> Cheers
>   Nick
>
>