Re: [PATCH RFC] audit: provide namespace information in user originated records
Eric Paris <eparis(a)redhat.com> writes:
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.
Hmm. I don't quite know how CAP_AUDIT_READ could work. When delivering
a message to a socket you really don't know who is on the other end.
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?)
One socket for each network namespace... It is a pain but doable.
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?
Messages generated by processes in that user namespace?
Going to have to have audit namespaces to. But only CAP_AUDIT_READ
would make sense in the new audit namespace...
Given the connection of audit and security I think if we add support for
a non-global auditd the user namespace seems to fit. The user namespace
is certainly where all of the security connected bits go.
Architecturally it gets a little tricky as it seems to make sense to
generate audit messages that make sense to the process receiving them,
which would mean actually generating a different audit message for
different receiving contexts.
I find the auditsc code odd. We log file descriptor numbers when a file
is mmaped? What is something so process relative good to anyone?
On a slightly different tangent. Do we want to update the AUDIT_CAPSET
message to report the user namespace whose caps we are changing or
perhaps to surpress the message outside of the initial user namespace.
Eric