Re: [PATCH RFC] audit: provide namespace information in user originated records
Quoting Eric Paris (eparis(a)redhat.com):
On Wed, 2013-03-20 at 13:36 -0500, Serge Hallyn wrote:
> Quoting Aristeu Rozanski (arozansk(a)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