linux-kernel - Re: [PATCH] userns/capability: Add user namespace capability

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]

Date:	Sun, 18 Oct 2015 20:28:07 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	Tobias Markus <tobias@...lix.eu>
Cc:	Richard Weinberger <richard.weinberger@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Andrew Morton <akpm@...uxfoundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Christoph Lameter <cl@...ux.com>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
	LSM <linux-security-module@...r.kernel.org>,
	"open list:ABI/API" <linux-api@...r.kernel.org>,
	linux-man <linux-man@...r.kernel.org>
Subject: Re: [PATCH] userns/capability: Add user namespace capability

On 18 Oct 2015 22:13, Tobias Markus wrote:
> On 17.10.2015 22:17, Richard Weinberger wrote:
> > On Sat, Oct 17, 2015 at 5:58 PM, Tobias Markus <tobias@...lix.eu> wrote:
> >> One question remains though: Does this break userspace executables that
> >> expect being able to create user namespaces without priviledge? Since
> >> creating user namespaces without CAP_SYS_ADMIN was not possible before
> >> Linux 3.8, programs should already expect a potential EPERM upon calling
> >> clone. Since creating a user namespace without CAP_SYS_USER_NS would
> >> also cause EPERM, we should be on the safe side.
> > 
> > In case of doubt, yes it will break existing software.
> > Hiding user namespaces behind CAP_SYS_USER_NS will not magically
> > make them secure.
> 
> The goal is not to make user namespaces secure, but to limit access to
> them somewhat in order to reduce the potential attack surface.

the irony is that disallowing non-privileged processes access to userns means
processes cannot jail themselves and thus make themselves more secure.  i've
been adding userns to various projects purely to get access to things like
mount, net, pid, sysv, and ipc namespaces.

putting this behind a cap also breaks the Chromium sandbox -- they were able
to drop set*id on the sandbox binary and utilize userns instead.
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md
https://code.google.com/p/chromium/issues/detail?id=312380
-mike

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)