From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Lutomirski <luto@MIT.EDU>
Subject: Re: [REVIEW][PATCH 0/43] Completing the user namespace
Date: Tue, 10 Apr 2012 12:01:31 -0700
Message-ID: <4F84838B.8000408@mit.edu>
References: <m11unyn70b.fsf@fess.ebiederm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Cyrill Gorcunov <gorcunov@openvz.org>,
	linux-security-module@vger.kernel.org,
	Al Viro <viro@ZenIV.linux.org.uk>,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
	Markus Gutschke <markus@chromium.org>,
	Will Drewry <wad@chromium.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from DMZ-MAILSEC-SCANNER-1.MIT.EDU ([18.9.25.12]:42612 "EHLO
	dmz-mailsec-scanner-1.mit.edu" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1753597Ab2DJTGk (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 10 Apr 2012 15:06:40 -0400
In-Reply-To: <m11unyn70b.fsf@fess.ebiederm.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On 04/07/2012 10:10 PM, Eric W. Biederman wrote:
> 
> This is a course correction for the user namespace, so that we can reach
> an inexpensive, maintainable, and reasonably complete implementation.
> 
> If anyone can think of a reason why the user namespace should not
> evolve in the direction taken in this patchset please let me know.
> 
> There is not an obvious maintainer for the scope of what this patchset
> covers so I intend to host this tree myself and to place it in
> linux-next after this round of review.
> 
> Highlights.
> - The kernel will now fail to build if you attempt to compile in
>   code whose permission checks have not been updated to be user
>   namespace safe.
> 
> - All uids from child user namespaces are mapped into the initial user
>   namespace before they are processed.  Removing the need to add
>   an additional check to see if the user namespace of the compared
>   uids remains the same.

[...]

I haven't read enough of the details to figure out how the uid mapping
works (do all the child namespace uids map to the same parent uid?), so
I may be missing some details here.

As a bit of background, the no_new_privs mode introduced in the big
seccomp patchset will add a flag that any task can set to prevent it or
any of its children from gaining privileges by using execve.

How should this interact with pid namespaces?  As a first pass, I
imagine that the main PR_SET_NO_NEW_PRIVS(1) mode will prevent setuid
from working inside uid namespaces as well, but there may be interest in
weaker variants that allow setuid inside namespaces.

Any thoughts?

--Andy