[linux] 05/05: ptrace: being capable wrt a process requires mapped uids/gids
debian-kernel at lists.debian.org
debian-kernel at lists.debian.org
Sun Dec 27 19:27:45 UTC 2015
This is an automated email from the git hooks/post-receive script.
benh pushed a commit to branch jessie-security
in repository linux.
commit 71fa22ff7499f42d6d92a786a926ebd6efcca399
Author: Ben Hutchings <ben at decadent.org.uk>
Date: Sun Dec 27 14:28:03 2015 +0000
ptrace: being capable wrt a process requires mapped uids/gids
---
debian/changelog | 1 +
...e-wrt-a-process-requires-mapped-uids-gids.patch | 102 +++++++++++++++++++++
debian/patches/series | 1 +
3 files changed, 104 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 532ae63..93490ae 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,7 @@ linux (3.16.7-ckt20-1+deb8u2) UNRELEASED; urgency=medium
(CVE-2015-8551, CVE-2015-8852, XSA-157)
* pptp: verify sockaddr_len in pptp_bind() and pptp_connect() (CVE-2015-8569)
* bluetooth: Validate socket address length in sco_sock_bind() (CVE-2015-8575)
+ * ptrace: being capable wrt a process requires mapped uids/gids
-- Ben Hutchings <ben at decadent.org.uk> Sun, 27 Dec 2015 14:20:54 +0000
diff --git a/debian/patches/bugfix/all/ptrace-being-capable-wrt-a-process-requires-mapped-uids-gids.patch b/debian/patches/bugfix/all/ptrace-being-capable-wrt-a-process-requires-mapped-uids-gids.patch
new file mode 100644
index 0000000..f9c9c92
--- /dev/null
+++ b/debian/patches/bugfix/all/ptrace-being-capable-wrt-a-process-requires-mapped-uids-gids.patch
@@ -0,0 +1,102 @@
+From: Jann Horn <jann at thejh.net>
+Subject: ptrace: being capable wrt a process requires mapped uids/gids
+Date: Sat, 26 Dec 2015 03:52:31 +0100
+Origin: https://lkml.org/lkml/2015/12/25/71
+
+ptrace_has_cap() checks whether the current process should be
+treated as having a certain capability for ptrace checks
+against another process. Until now, this was equivalent to
+has_ns_capability(current, target_ns, CAP_SYS_PTRACE).
+
+However, if a root-owned process wants to enter a user
+namespace for some reason without knowing who owns it and
+therefore can't change to the namespace owner's uid and gid
+before entering, as soon as it has entered the namespace,
+the namespace owner can attach to it via ptrace and thereby
+gain access to its uid and gid.
+
+While it is possible for the entering process to switch to
+the uid of a claimed namespace owner before entering,
+causing the attempt to enter to fail if the claimed uid is
+wrong, this doesn't solve the problem of determining an
+appropriate gid.
+
+With this change, the entering process can first enter the
+namespace and then safely inspect the namespace's
+properties, e.g. through /proc/self/{uid_map,gid_map},
+assuming that the namespace owner doesn't have access to
+uid 0.
+Changed in v2: The caller needs to be capable in the
+namespace into which tcred's uids/gids can be mapped.
+
+Signed-off-by: Jann Horn <jann at thejh.net>
+---
+ kernel/ptrace.c | 33 ++++++++++++++++++++++++++++-----
+ 1 file changed, 28 insertions(+), 5 deletions(-)
+
+--- a/kernel/ptrace.c
++++ b/kernel/ptrace.c
+@@ -20,6 +20,7 @@
+ #include <linux/uio.h>
+ #include <linux/audit.h>
+ #include <linux/pid_namespace.h>
++#include <linux/user_namespace.h>
+ #include <linux/syscalls.h>
+ #include <linux/uaccess.h>
+ #include <linux/regset.h>
+@@ -213,12 +214,34 @@ static int ptrace_check_attach(struct ta
+ return ret;
+ }
+
+-static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
++static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
+ {
++ struct user_namespace *tns = tcred->user_ns;
++
++ /* When a root-owned process enters a user namespace created by a
++ * malicious user, the user shouldn't be able to execute code under
++ * uid 0 by attaching to the root-owned process via ptrace.
++ * Therefore, similar to the capable_wrt_inode_uidgid() check,
++ * verify that all the uids and gids of the target process are
++ * mapped into a namespace below the current one in which the caller
++ * is capable.
++ * No fsuid/fsgid check because __ptrace_may_access doesn't do it
++ * either.
++ */
++ while (
++ !kuid_has_mapping(tns, tcred->euid) ||
++ !kuid_has_mapping(tns, tcred->suid) ||
++ !kuid_has_mapping(tns, tcred->uid) ||
++ !kgid_has_mapping(tns, tcred->egid) ||
++ !kgid_has_mapping(tns, tcred->sgid) ||
++ !kgid_has_mapping(tns, tcred->gid)) {
++ tns = tns->parent;
++ }
++
+ if (mode & PTRACE_MODE_NOAUDIT)
+- return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
++ return has_ns_capability_noaudit(current, tns, CAP_SYS_PTRACE);
+ else
+- return has_ns_capability(current, ns, CAP_SYS_PTRACE);
++ return has_ns_capability(current, tns, CAP_SYS_PTRACE);
+ }
+
+ /* Returns 0 on success, -errno on denial. */
+@@ -247,7 +270,7 @@ static int __ptrace_may_access(struct ta
+ gid_eq(cred->gid, tcred->sgid) &&
+ gid_eq(cred->gid, tcred->gid))
+ goto ok;
+- if (ptrace_has_cap(tcred->user_ns, mode))
++ if (ptrace_has_cap(tcred, mode))
+ goto ok;
+ rcu_read_unlock();
+ return -EPERM;
+@@ -258,7 +281,7 @@ ok:
+ dumpable = get_dumpable(task->mm);
+ rcu_read_lock();
+ if (dumpable != SUID_DUMP_USER &&
+- !ptrace_has_cap(__task_cred(task)->user_ns, mode)) {
++ !ptrace_has_cap(__task_cred(task), mode)) {
+ rcu_read_unlock();
+ return -EPERM;
+ }
diff --git a/debian/patches/series b/debian/patches/series
index a9b09d6..7ace09a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -663,3 +663,4 @@ bugfix/all/xen-pciback-for-xen_pci_op_disable_msi-x-only-disabl.patch
bugfix/all/xen-pciback-don-t-allow-msi-x-ops-if-pci_command_mem.patch
bugfix/all/pptp-verify-sockaddr_len-in-pptp_bind-and-pptp_conne.patch
bugfix/all/bluetooth-validate-socket-address-length-in-sco_sock.patch
+bugfix/all/ptrace-being-capable-wrt-a-process-requires-mapped-uids-gids.patch
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/kernel/linux.git
More information about the Kernel-svn-changes
mailing list