[Bug dynamic-link/30134] DT_AUDIT is ignored for dlopen()ed solib

["stsp at users dot sourceforge.net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30134

--- Comment #7 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Florian Weimer from comment #6)
> If the auditor cannot intercept libc.so.6 calls because it is already
> loaded, then it can even use the main libc.so.6, and no fully separate
> namespace is needed at all.

Certainly I don't know the implications,
but in all projects where I needed to
intercept the glibc calls I was using
LD_PRELOAD (or the more advanced techniques
like dlmopen() the libc into another
namespace and intercept it there), but
not LD_AUDIT. I've yet to understand is
there something special in those complex
pltenter/pltexit call-backs that you can't
do by some other means, and are there
many/any users of them?
But having audit modules in the main
namespace would help me a lot.

Also wrt security hardening you mentioned,
I wonder if such a measure (making audit
list R/O) was applied exactly because of
those pltenter/pltexit call-backs, that
looks like the good target for code injection?
If you had some subclass of "simple"
auditors that only assist the dlopen()
functionality, then would you still mark
the list of such "simple" auditors read-only?
Maybe we need the subclass of "simple"
or "safe" auditors that would be allowed
to load at run-time?
Is there any write-up about the objectives
and the desired functionality of that
auditing frame-work, or was it evolving
chaotically and eventually became a
potential security risk?

-- 
You are receiving this mail because:
You are on the CC list for the bug.