Re: Thoughts on tightening up user namespace creation

From: Kees Cook
Date: Wed Mar 09 2016 - 14:25:54 EST

On Wed, Mar 9, 2016 at 11:21 AM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote:
> Quoting Colin Walters (walters@xxxxxxxxxx):
>> On Wed, Mar 9, 2016, at 01:14 PM, Kees Cook wrote:
>> > On Mon, Mar 7, 2016 at 9:15 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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:
>> >
>> >
>> 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.

> 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 Cook
Chrome OS & Brillo Security