Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753967AbcCHGHH (ORCPT ); Tue, 8 Mar 2016 01:07:07 -0500 Received: from h2.hallyn.com ([78.46.35.8]:43002 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751534AbcCHGG7 (ORCPT ); Tue, 8 Mar 2016 01:06:59 -0500 Date: Tue, 8 Mar 2016 00:06:57 -0600 From: "Serge E. Hallyn" To: Andy Lutomirski Cc: "linux-kernel@vger.kernel.org" , "Eric W. Biederman" , Linux Containers , Alexander Larsson , Colin Walters , Serge Hallyn , Stephane Graber , Kees Cook , Seth Forshee Subject: Re: Thoughts on tightening up user namespace creation Message-ID: <20160308060657.GA3565@mail.hallyn.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3793 Lines: 86 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@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/containers