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: <1457549467.650797.544465346.49653120@webmail.messagingengine.com>
Date:	Wed, 09 Mar 2016 13:51:07 -0500
From:	Colin Walters <walters@...bum.org>
To:	Kees Cook <keescook@...omium.org>,
	Andy Lutomirski <luto@...capital.net>
Cc:	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

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 
writing setuid binaries that expose some of the features, but e.g. not
CAP_NET_ADMIN.

Andy's suggestion of having this be a per-namespace setting makes
sense to me.  Currently some container tools that do use userns
are by default denying it to be recursive (Sandstorm.io and Docker 1.10 at least)
by using a seccomp filter on clone().  If we had this setting that
filter wouldn't be necessary, and would solve the issue that seccomp filters
aren't robust against the kernel adding new API, e.g. a new CLONE_NEWUSER_NONEWPRIVS
which might enable chroot() but not CAP_NET_ADMIN.