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:	Sat, 17 Oct 2015 16:55:01 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Tobias Markus <tobias@...lix.eu>
Cc:	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>,
	linux-security-module@...r.kernel.org, linux-api@...r.kernel.org,
	linux-man@...r.kernel.org
Subject: Re: [PATCH] userns/capability: Add user namespace capability

On Sat, Oct 17, 2015 at 05:58:04PM +0200, Tobias Markus wrote:
> Add capability CAP_SYS_USER_NS.
> Tasks having CAP_SYS_USER_NS are allowed to create a new user namespace
> when calling clone or unshare with CLONE_NEWUSER.
> 
> Rationale:
> 
> Linux 3.8 saw the introduction of unpriviledged user namespaces,
> allowing unpriviledged users (without CAP_SYS_ADMIN) to be a "fake" root
> inside a separate user namespace. Before that, any namespace creation
> required CAP_SYS_ADMIN (or, in practice, the user had to be root).
> Unfortunately, there have been some security-relevant bugs in the
> meantime. Because of the fairly complex nature of user namespaces, it is
> reasonable to say that future vulnerabilties can not be excluded. Some
> distributions even wholly disable user namespaces because of this.

Fwiw I'm not in favor of this.  Debian has a patch (I believe the one
I originally wrote for Ubuntu but which Ubuntu dropped long ago) adding a
sysctl, off by default, for enabling user namespaces.

Posix capabilities are intended for privileged actions, not for
actions which explicitly should not require privilege, but which
we feel are in development.

In general, the feeling is that putting a feature like this behind a
wall will only slow down the finding of any bugs, so I think the goal
itself is questionable.  But the chosen means for achieving your goal
are definately wrong.

> Both options, user namespaces with and without CAP_SYS_ADMIN, can be
> said to represent the extreme end of the spectrum. In practice, there is
> no reason for every process to have the abilitiy to create user
> namespaces. Indeed, only very few and specialized programs require user

There is.  One of Eric's primary motivations for user namespaces was to
finally allow unprivileged users to safely do things like manipulate
their mounts tree without the risk of privileged (setuid) programs
being tricked.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ