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

[Eric Paris]

On Wed, 2013-03-20 at 13:49 -0500, Serge Hallyn wrote:
> 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.

[veering away from this particular patch]

We are also talking about adding a CAP_AUDIT_READ and sending messages
via multicast on the audit socket.  The problem is I don't know how the
audit socket could work in the network namespace world.  Right now
kauditd has:

audit_sock = netlink_kernel_create(&init_net, NETLINK_AUDIT, &cfg);

So there won't ever be anything on the kernel side of the audit socket
in a non-init network namespace.  Lets say that is fixed somehow (I
assume it's possible?  something? magic pixies?) I think we'd somehow
need to do the CAP_AUDIT_READ check against the user namespace
associated with the network namespace in question?  But what messages
should go to this userspace auditd?

Going to have to have audit namespaces to.  But only CAP_AUDIT_READ
would make sense in the new audit namespace...

/me wishes containers were a 'thing' instead of a bucket of semi-related
nuts and bolts.

-Eric