[PATCH RFC] audit: provide namespace information in user originated records

[Serge Hallyn]

Quoting Eric Paris (eparis at redhat.com):
> On Wed, 2013-03-20 at 13:36 -0500, Serge Hallyn wrote:
> > Quoting Aristeu Rozanski (arozansk at redhat.com):
> > > This is a bit fuzzy to me, perhaps due I'm not fully understanding
> > > userns implementation yet, so bear with me:
> > > I thought of changing so userns would not grant CAP_AUDIT_WRITE and
> > > CAP_AUDIT_CONTROL unless the process already has it (i.e. it'd require
> > 
> > Seems like CAP_AUDIT_WRITE should be targeted against the
> > skb->netns->userns.  Then CAP_AUDIT_WRITE can be treated like any other
> > capability.  Last I knew (long time ago) you had to be in init_user_ns
> > to talk audit, but that's ok - this would just do the right thing in
> > any case.
> 
> kauditd should be considered as existing in the init user namespace.  So
> I'd think we'd want to check if the process had CAP_AUDIT_WRITE in the
> init user namespace and if so, allow it to send messages.  Who care what
> *ns the process exists in.  If it has it in the init namespace, go
> ahead.  Thus the process that created the container would need
> CAP_AUDIT_WRITE in the init namespace for this to all work, right?

Yes.  What I was suggesting is intended to work if that situation ever
changes.  But I have zero complaints about doing it as you say, as I
doubt it ever will/ought to change.

That basically means CAP_AUDIT_WRITE would be worthless in a non-init
userns.  That's fine - at least the rules would be consistent.

> /me also gets so confused about what caps mean in the userns world.

If the resource in question (like a network interface) belongs to a
namespace (netns) created by the userns in which the caller has the caps
in question, then privilege is granted.

Otherwise, not.

What you're saying above about CAP_AUDIT_WRITE is exactly right (for
how audit works right now).

> (/me has larger issues with the ns concept as a whole, but that boat
> sailed years and years ago)

-serge