linux-kernel - [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-next>] [day] [month] [year] [list]
Date:	Sat, 17 Oct 2015 17:58:04 +0200
From:	Tobias Markus <tobias@...lix.eu>
To:	linux-kernel@...r.kernel.org
Cc:	"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: [PATCH] userns/capability: Add user namespace capability

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.

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
namespaces. This seems to be a perfect fit for the (file) capability
system: Priviledged users could manually allow only a certain executable
to be able to create user namespaces by setting a certain capability,
I'd suggest the name CAP_SYS_USER_NS. Executables completely unrelated
to user namespaces should and can not create them.

The capability should only be required in the "root" user namespace (the
user namespace with level 0) though, to allow nested user namespaces to
work as intended. If a user namespace has a level greater than 0, the
original process must have had CAP_SYS_USER_NS, so it is "trusted" anyway.

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.

Cc: linux-security-module@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Cc: linux-api@...r.kernel.org
Cc: linux-man@...r.kernel.org
Cc: Eric W. Biederman <ebiederm@...ssion.com>
Cc: Al Viro <viro@...iv.linux.org.uk>
Cc: Serge Hallyn <serge.hallyn@...onical.com>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Christoph Lameter <cl@...ux.com>
Cc: Michael Kerrisk <mtk.manpages@...il.com>
Signed-off-by: Tobias Markus <tobias@...lix.eu>
---
 include/uapi/linux/capability.h     | 5 ++++-
 kernel/cred.c                       | 7 ++++++-
 security/selinux/include/classmap.h | 2 +-
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 12c37a1..d83540f 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -351,8 +351,11 @@ struct vfs_cap_data {
  #define CAP_AUDIT_READ		37
 +/* Allow creating user namespaces (CLONE_NEWUSER) using clone() and unshare() */
 -#define CAP_LAST_CAP         CAP_AUDIT_READ
+#define CAP_SYS_USER_NS      38
+
+#define CAP_LAST_CAP         CAP_SYS_USER_NS
  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 diff --git a/kernel/cred.c b/kernel/cred.c
index 71179a0..847d499 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -345,7 +345,12 @@ int copy_creds(struct task_struct *p, unsigned long clone_flags)
 		return -ENOMEM;
  	if (clone_flags & CLONE_NEWUSER) {
-		ret = create_user_ns(new);
+		if (new->user_ns->level == 0 &&
+		    !has_capability(p, CAP_SYS_USER_NS)) {
+			ret = -EPERM;
+		} else {
+			ret = create_user_ns(new);
+		}
 		if (ret < 0)
 			goto error_put;
 	}
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index 5a4eef5..07cec76 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -39,7 +39,7 @@ struct security_class_mapping secclass_map[] = {
 	    "linux_immutable", "net_bind_service", "net_broadcast",
 	    "net_admin", "net_raw", "ipc_lock", "ipc_owner", "sys_module",
 	    "sys_rawio", "sys_chroot", "sys_ptrace", "sys_pacct", "sys_admin",
-	    "sys_boot", "sys_nice", "sys_resource", "sys_time",
+	    "sys_boot", "sys_nice", "sys_resource", "sys_time", "sys_user_ns",
 	    "sys_tty_config", "mknod", "lease", "audit_write",
 	    "audit_control", "setfcap", NULL } },
 	{ "filesystem",
-- 
2.6.1

--
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/