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

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:

> Quoting Eric Paris (eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>> So the kernel socket(s) would be per network namespace, but we divide
>> messages per user namespace?  Which socket do I send them on,
>> considering the possible crazy many<->many mappings between user and
>> network namespaces.  It all makes me cry a little.
>
> not many-many - each netns is owned by exactly one userns.  The userns
> from which the netns was created.

Doh.  I missed this question and I think I misunderstood when Eric
Paris was talking about multicasting audit messages.

If what we are really talking about is sending some audit messages to
an auditd in a container what appears obvious to me is that we define
a per user namespace capability something like CAP_AUDIT_CONTROL.  That
does most or all of what CAP_AUDIT_CONTROL does in the init user
namespace.  Especially capturing audit_pid and audit_nlk_portid to
decide who to send the message to.

Something like:

struct audit_control {
	int	initialized;
	pid_t	pid;
	u32	nlk_portid;
};

struct user_namespace {
       ...
       struct audit_contol audit;
};

Then the transmission would be something like:
	struct user_namespace *user_ns = ...;
        for (;;) {
		if (ns->audit_pid) {
        		err = netlink_unicast(ns->audit.sock, skb, ns->audit.nlk_portid, 0);
		}
                if (!ns->parent)
                	break;
		ns = ns->parent;
	}

If someone finds auditd interesting enough to do that work.

In general I think it only makes sense if we can reuse the existing
userspace auditd.

Eric