Re: [Part1 PATCH 00/22] Add namespace support for audit

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

Aristeu Rozanski <aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:

> On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote:
>> Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> writes:
>> 
>> > On 06/20/2013 11:02 AM, Gao feng wrote:
>> >> If we don't tie audit to user namespace, there is still one problem.
>> >
>> > One more problem. some audit messages are generated by some net subsystem
>> > such as netfilter. If we don't tie audit to user namespace, we have no
>> > idea where these audit messages should go. there is no relationship between
>> > net namespace and audit namespace while we can get user namespace through
>> > net user namespace.
>> 
>> I am in favor of the user namespace tie in.
>> 
>> I am in favor of running a per user namespace audit filter once per user
>> namespace walking up the user namespace hierarchy.  Each filter would
>> deliver messages to a different userspace audit daemon.
>> 
>> Until we agreement to go that far I am not certain the kernel generated
>> audit messages should go anywhere except to the global audit daemon.
>> 
>> I think on an individual basis we can look at kernel audit messages and
>> see if they should go to just the global user namespace.  Just the user
>> namspace of the relevant network stack.  Or if the message should go to
>> the audit daemon of every user namespace that is an ancestor of some
>> starting user namespace.
>> 
>> But please let's error on the side of caution here.
>
> Let's say I'd like to use userns but still have a single and global
> auditd.

By definition the kernel auditd functionality is broken if we don't
allow a global auditd.  So that will be allowed.

> Dropping the capability will be required for that?

No.  Dropping capabilities and being in a state where you can never
interact with the primary audit context is required to safely have
access to a subordinate audit context.  Never being able to intereact
with the primary audit context removes all possibility of confusing
a privileged application and break the security model.

Entering a user namespace by definition drops all capabilities in a
non-recoverable way.  Which makes being in a user namespace a sufficient
condition to use a subordinate audit context.

> That sounds
> bad. The fact new user namespaces will want to control the separated
> audit namespace doesn't require tie in.

No.  The fact that you can gain root privileges by executing a suid root
application when not in a user namespace requires a tie in.


In summary.  A subordinate audit context is not safe if you can still
execute a suid root application and become root.  The interesting use
case is inside of a user namespace, which never allows gaining
capabilities outside of the user namespace.  Which makes a tie in with
user namespaces sensible, as it never allows subverting the current
mechanisms and it is where people want the functionality.

Eric