From: ebiederm@xmission.com (Eric W. Biederman)
To: Aristeu Rozanski <aris@redhat.com>
Cc: Gao feng <gaofeng@cn.fujitsu.com>, containers@lists.linux-foundation.org,
        serge.hallyn@ubuntu.com, linux-kernel@vger.kernel.org,
        Eric Paris <eparis@redhat.com>, linux-audit@redhat.com,
        matthltc@linux.vnet.ibm.com, sgrubb@redhat.com
References: <1371606834-5802-1-git-send-email-gaofeng@cn.fujitsu.com>
	<20130619204927.GJ3212@redhat.com>
	<1371675095.16587.5.camel@dhcp137-13.rdu.redhat.com>
	<51C270AF.1080902@cn.fujitsu.com> <51C27266.3060909@cn.fujitsu.com>
	<87y5a4phlm.fsf@xmission.com> <20130624150237.GA3535@redhat.com>
Date: Mon, 24 Jun 2013 12:03:48 -0700
In-Reply-To: <20130624150237.GA3535@redhat.com> (Aristeu Rozanski's message of
	"Mon, 24 Jun 2013 11:02:37 -0400")
Message-ID: <87a9mfl4a3.fsf@xmission.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Part1 PATCH 00/22] Add namespace support for audit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3115
Lines: 70

Aristeu Rozanski <aris@redhat.com> writes:

> On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote:
>> Gao feng <gaofeng@cn.fujitsu.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/