UBUNTU: ubuntu: Yama - add ptrace relationship tracking interface

Some application suites have external crash handlers that depend
on being able to use ptrace to generate crash reports (KDE, Wine,
Chromium, Firefox, etc). Since the inferior process has a defined
application-specific relationship with the debugger, allow the inferior
to express that relationship by declaring who can call PTRACE_ATTACH
against it. The inferior can use prctl() with PR_SET_PTRACER to allow a
specific PID and its descendants to perform the ptrace instead of only
a direct ancestor.

Signed-off-by: Kees Cook <kees.cook@canonical.com>
---
v2:
 - kmalloc, spinlock init, and doc typo corrections from Tetsuo Handa.
 - make sure to replace if possible on add, thanks to Eric Paris.
v3:
 - make sure to use thread group leader when searching for exceptions.
v4:
 - make sure to use thread group leader when creating exceptions.
v5:
 - make sure to use thread group leader when deleting exceptions.

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

1 files changed, 25 insertions, 13 deletions

diff --git a/Documentation/Yama.txt b/Documentation/Yama.txt
index f9f15d23055..b83c02a2d97 100644
--- a/Documentation/Yama.txt
+++ b/Documentation/Yama.txt
@@ -1,5 +1,5 @@
 Yama is a Linux Security Module that collects a number of security
-protections that are not handled by the core kernel itself.  To select
+protections that are not handled by the core kernel itself. To select
 it at boot time, specify "security=yama" (though this will disable any
 other LSM).
 
@@ -17,7 +17,7 @@ A long-standing class of security issues is the symlink-based
 time-of-check-time-of-use race, most commonly seen in world-writable
 directories like /tmp. The common method of exploitation of this flaw
 is to cross privilege boundaries when following a given symlink (i.e. a
-root process follows a symlink belonging to another user).  For a likely
+root process follows a symlink belonging to another user). For a likely
 incomplete list of hundreds of examples across the years, please see:
 http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
 
@@ -67,24 +67,36 @@ of their attack without resorting to user-assisted phishing.
 This is not a theoretical problem. SSH session hijacking
 (http://www.storm.net.nz/projects/7) and arbitrary code injection
 (http://c-skills.blogspot.com/2007/05/injectso.html) attacks already
-exist and remain possible if PTRACE is allowed to operate as before.
-PTRACE is not commonly used by non-developers and non-admins, so system
+exist and remain possible if ptrace is allowed to operate as before.
+Since ptrace is not commonly used by non-developers and non-admins, system
 builders should be allowed the option to disable this debugging system.
 
 For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to
-specifically disallow such PTRACE attachment (e.g. ssh-agent), but many
-do not. A more general solution is to only allow PTRACE directly from a
+specifically disallow such ptrace attachment (e.g. ssh-agent), but many
+do not. A more general solution is to only allow ptrace directly from a
 parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
 work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
 still work as root).
 
-0 - classic PTRACE permissions: a process can PTRACE any other process
-    running under the same uid, as long as it is dumpable (i.e. did not
-    transition uids, start privileged, or have prctl(PR_SET_DUMPABLE...)
-    called).
-
-1 - child-only PTRACE: a process can PTRACE only its descendants when
-    the above classic criteria is also met.
+For software that has defined application-specific relationships
+between a debugging process and its inferior (crash handlers, etc),
+prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which
+other process (and its descendents) are allowed to call PTRACE_ATTACH
+against it. For example, this is used by KDE, Chromium, and Firefox's
+crash handlers, and by Wine for allowing only Wine processes to ptrace
+each other.
+
+0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
+    process running under the same uid, as long as it is dumpable (i.e.
+    did not transition uids, start privileged, or have called
+    prctl(PR_SET_DUMPABLE...) already).
+
+1 - restricted ptrace: a process must have a predefined relationship
+    with the inferior it wants to call PTRACE_ATTACH on. By default,
+    this relationship is that of only its descendants when the above
+    classic criteria is also met. To change the relationship, an
+    inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
+    an allowed debugger PID to call PTRACE_ATTACH on the inferior.
 
 This protection is based on the restrictions in grsecurity.