Future directions for the dynamic linker auditing (LD_AUDIT) interface

[Florian Weimer]

This message is partly in response to this bug report:

  Bug 31992 - Dynamic linker auditors need to be able to audit each
  other.
  <https://sourceware.org/bugzilla/show_bug.cgi?id=31992>

We have fix quite a few auditing issues over the last few releases, and
have also implemented some small enhancements.  With increased usage of
auditors over LD_PRELOAD and symbol interposition, this has led to more
gaps being identified, and concerns about the overall design of the
auditing interface.  Now that more dynamic linker functionality works
from auditors, new questions arise, like what happens if an auditor
calls dlmopen on the main namespace and there is another auditor
present.  Should the other auditor be given the opportunity to redirect
the object for the dlmopen call?  Should that depend on auditor
ordering?  Is it necessary or even desirable to load different auditors
into separate namespaces, like we do today? And so on.

However, I do not think we can implement multi-auditor enhancements
without understanding first the different auditing use cases are, and
how they might interact in the same executable.  Any from-scratch design
we can produce on the glibc side would not benefit from field
experience.

However, I think we now provide the necessarily tools so that it's
possible to implement a general-purpose auditing shim, and this shim can
load further plugins using dlopen.  These plugins probably should not
export the existing audit callbacks (la_activty etc.), but something
specific to the shim.  In the other direction, it would make sense to
call wrappers provided by the shim instead of dlopen etc. directly.  The
shim would broadcast auditing events to the plugins, and combine what
the plugins report.  It may make sense to apply multiple conflict
resolution strategies (order-based, priority-based, iteration until a
fixpoint is reached, etc.) depending on the dispatched event.  This is
an area where the shim could help us to gather information about what
works in practice.  Once we know what a working interface looks like, we
can explore how to merge it into glibc proper.

We should keep fixing bugs, of course.  In particular, this includes the
fixes currently under review, and issues that cause application failures
in the presence of an auditor that cannot be worked around in the
auditor, such as the static TLS allocation problem.  We can also add
more queries for dlinfo.  At this point, adding more callbacks (for
example, for adding completely new symbols) is more challenging, and
would need some prototyping, I think.  However, I do not want us to come
up with an API that mediates between different auditors, without having
seen a prototype first.

Thanks,
Florian