Message-ID: <20160308060657.GA3565@mail.hallyn.com>
Date:	Tue, 8 Mar 2016 00:06:57 -0600
From:	"Serge E. Hallyn" <serge.hallyn@...ntu.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linux Containers <containers@...ts.linux-foundation.org>,
	Alexander Larsson <alexl@...hat.com>,
	Colin Walters <walters@...bum.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Stephane Graber <stgraber@...ntu.com>,
	Kees Cook <keescook@...omium.org>,
	Seth Forshee <seth.forshee@...onical.com>
Subject: Re: Thoughts on tightening up user namespace creation

On Mon, Mar 07, 2016 at 09:15:25PM -0800, Andy Lutomirski wrote:
> Hi all-
> 
> There are several users and distros that are nervous about user
> namespaces from an attack surface point of view.
> 
>  - RHEL and Arch have userns disabled.
> 
>  - Ubuntu requires CAP_SYS_ADMIN

No, it does not.  It has temporarily re-added a sysctl which can enable
that behavior, but it's not set by default.  The reason for providing it
is not a distrust of user namespaces in general, but because we're enabling
some bleeding edge patches which haven't been accepted upstream yet.  Once
they're accepted upstream I expect that patch to be dropped again, unless
it has gone upstream.

Debian does afaik still have a version of a patch I'd originally written
before user namespaces were upstream which defaulted unprivileged userns
cloning to off.  Did you mean Debian here?

>  - Kees periodically proposes to upstream some sysctl to control
> userns creation.
> 
> I think there are three main types of concerns.  First, there might be
> some as-yet-unknown semantic issues that would allow privilege
> escalation by users who create user namespaces and then confuse
> something else in the system.  Second, enabling user namespaces
> exposes a lot of attack surface to unprivileged users.  Third,
> allowing tasks to create user namespaces exposes the kernel to various
> resource exhaustion attacks that wouldn't be possible otherwise.
> 
> Since I doubt we'll ever fully address the attack surface issue at
> least, would it make sense to try to come up with an upstreamable way
> to limit who can create new user namespaces and/or do various
> dangerous things with them?
> 
> I'll divide the rest of the email into the "what" and the "who".
> 
> +++ What does the privilege of creating a user namespace entail? +++
> 
> This could be an all-or-nothing thing.  It would certainly be possible
> for appropriately privileged tasks to be able to unshare namespaces
> and use their facilities exactly like any task can in a current
> user-ns-enabled kernel and for other tasks to be unable to unshare
> anything.
> 
> Finer gradations are, in principle, possible.  For example, it could
> be possible for a given task to unshare its userns but to have limited
> caps inside or to be unable to unshare certain other namespaces.  For
> example, maybe a task could unshare userns and mount ns but not net
> ns.  I don't think this would be particularly useful.
> 
> It might be more interesting to allow a task to unshare all
> namespaces, hold all capabilities in them, but to still be unable to
> use certain privileged facilities.  For example, maybe denying
> administrative control over iptables, creation of exotic network
> interface types, or similar would make sense.  I don't know how we'd
> specify this type of constraint.
> 
> +++ Who can create user namespaces (possibly with restrictions)? +++
> 
> I can think of a few formulations.
> 
> A simpler approach would be to add a per-namespace setting listing
> users and/or groups that can unshare their userns.  A userns starts
> out allowing everyone to unshare userns, and anyone with CAP_SYS_ADMIN
> can change the setting.
> 
> A fancier approach would be to have an fd that represents the right to
> unshare your userns.  Some privilege broker could give out those fds
> to apps that need them and meet whatever criteria are set.  If you try
> to unshare your userns without the fd, it falls back to some simpler
> policy.
> 
> I think I prefer the simpler one.  It's simple, and I haven't come up
> with a concrete problem with it yet.
> 
> 
> 
> 
> Thoughts?
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers

Powered by blists - more mailing lists