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:49 -0500, Serge Hallyn wrote:
> 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.
[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.
Right.
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?
Ones which pertain to resources in that userns. If we ever were to
sprinkle that pixie dust, then we'd know how to do this as well :)
Going to have to have audit namespaces to. But only CAP_AUDIT_READ
would make sense in the new audit namespace...
It's not clear to me that an audit namespace is needed. The userns
'owns' other namespaces, so it seems like it should suffice for
directing audit msgs.
/me wishes containers were a 'thing' instead of a bucket of
semi-related
nuts and bolts.
That sure would simplify things. However there definately are heavy
users of individual namespaces - i.e. using thousands of network
namespaces but no other namespaces.
-serge