Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933926AbcCITZw (ORCPT ); Wed, 9 Mar 2016 14:25:52 -0500 Received: from mail-io0-f178.google.com ([209.85.223.178]:33446 "EHLO mail-io0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933551AbcCITZn (ORCPT ); Wed, 9 Mar 2016 14:25:43 -0500 MIME-Version: 1.0 In-Reply-To: <20160309192103.GA2523@mail.hallyn.com> References: <1457549467.650797.544465346.49653120@webmail.messagingengine.com> <20160309192103.GA2523@mail.hallyn.com> Date: Wed, 9 Mar 2016 11:25:42 -0800 X-Google-Sender-Auth: g05lbaQyuNKrHaPzGKZFJaPwCg8 Message-ID: Subject: Re: Thoughts on tightening up user namespace creation From: Kees Cook To: "Serge E. Hallyn" Cc: Colin Walters , Andy Lutomirski , LKML , "Eric W. Biederman" , Linux Containers , Alexander Larsson , Serge Hallyn , Stephane Graber , Seth Forshee Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2560 Lines: 59 On Wed, Mar 9, 2016 at 11:21 AM, Serge E. Hallyn wrote: > Quoting Colin Walters (walters@verbum.org): >> On Wed, Mar 9, 2016, at 01:14 PM, Kees Cook wrote: >> > On Mon, Mar 7, 2016 at 9:15 PM, 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 >> > > >> > > - Kees periodically proposes to upstream some sysctl to control >> > > userns creation. >> > >> > And here's another ring0 escalation flaw, made available to >> > unprivileged users because of userns: >> > >> > https://code.google.com/p/google-security-research/issues/detail?id=758 >> >> Looks like Andy won't have to eat his hat ;) >> >> > The change in attack surface is _substantial_. We must have a way to >> > globally disable userns. >> >> No one would object if it was enabled but only accessible to >> CAP_SYS_ADMIN though, right? This could be useful for > > I think that would be terrible. I'd have to expose all of CAP_SYS_ADMIN > to allow use of CLONE_NEWUSER. I'd be more interested in a new CAP_NEWUSER > capability. Then systems wanting to support unprivileged users doing user > namespaces could set a pam module giving certain users that cap in pI, and > set it on fI on their container managers. Userspace has to give access to > mapped uids through /etc/subuid too, so it's not *so* huge added hurdle. > Well that's not quite true - with empty subuid, users can create a userns > with no mapped userids which in itself is useful for sandboxing. > > The biggest problem with a CAP_NEWUSER would be that it's more inherently > permanent than a new sysctl. The increase in attack surface is real, but > over time I'd like to think that we will have dealt with it and should be > able to make CLONE_NEWUSER unprivileged. Because what we have is an > implementation issue (not in user namespaces), not a design issue. Andy suggested a capability back in October. But I agree with you, we don't want a new capability. https://lkml.org/lkml/2015/10/17/94 > And I do agree the issue is real. And I fully expect for the issue to improve over time: it's not that I don't want userns, I just want to have the _option_ to disable it at runtime for the systems that don't need it until the newly exposed interfaces look like they've had the bulk of their issues resolved. -Kees -- Kees Cook Chrome OS & Brillo Security