[systemd-devel] [PATCH] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]

[Serge Hallyn]

Quoting Lennart Poettering (lennart at poettering.net):
> On Wed, 20.05.15 22:40, Martin Pitt (martin.pitt at ubuntu.com) wrote:
> 
> > Hey Lennart,
> > 
> > Lennart Poettering [2015-05-20 17:49 +0200]:
> > > Nope, ConditionSecurity=audit is only a simple boolean check that
> > > holds when audit is enabled at all. It doesn't tell you anything about
> > > the precise audit feature set of the kernel.
> > 
> > Ah, thanks for the clarification.
> > 
> > > I have now conditionalized the unit on CAP_ADMIN_READ, which is the
> > > cap that you need to read the audit multicast stuff. You container
> > > manager hence should simply drop that cap fro, the cap set it passes
> > > and all should be good.

I want to clarify this point.  Dropping CAP_ADMIN_READ from the bounding
set means dropping it from the capabilities targeted at your own user
namespace.  The only check in the kernel for CAP_ADMIN_READ currently is
against the initial user namespace.  One day of course (maybe soon) this
may change so that you only need CAP_ADMIN_READ against your own
user_ns.  Following the above, container managers could then again keep
CAP_ADMIN_READ in the bounding set.

But I'm claiming that checking for CAP_ADMIN_READ in your bounding set
is the wrong check here.  It simply has nothing to do with what you
actually want to be able to do.  One could argue that the right answer
is a new kernel facility to check for caps against init_user_ns, but no
that will have the same problem after audit ns becomes possible.  I
think the right check for systemd to perform to check whether this is
allowed is to actuallly try the bind().  That will return the right
answer both now and when namespaced audit is possible, without taking a
probably-wrong unrelated cue from the container manager.

It's not earth-shatteringly important and what you've got is workable,
but I think it may set a better precedent to do it the other way.

-serge

(One might almost think that we should have a new kernel facility to
answer questions such questions.  CAP_MAC_ADMIN is similar.)