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

Eric W. Biederman
2013-03-20T23:23:32Z

Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:

> On Wed, 2013-03-20 at 13:49 -0500, Serge Hallyn wrote:
>> Quoting Eric Paris (eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>> > On Wed, 2013-03-20 at 13:36 -0500, Serge Hallyn wrote:
>> > > Quoting Aristeu Rozanski (arozansk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>> > > > 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