linux-kernel - Re: Thoughts on tightening up user namespace creation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

Quoting Colin Walters (walters@...bum.org):
> On Wed, Mar 9, 2016, at 01:14 PM, Kees Cook wrote:
> > On Mon, Mar 7, 2016 at 9:15 PM, Andy Lutomirski <luto@...capital.net> 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.

And I do agree the issue is real.

-serge