Yama: add additional ptrace scopes
[linux-3.10.git] / Documentation / security / Yama.txt
1 Yama is a Linux Security Module that collects a number of system-wide DAC
2 security protections that are not handled by the core kernel itself. To
3 select it at boot time, specify "security=yama" (though this will disable
4 any other LSM).
5
6 Yama is controlled through sysctl in /proc/sys/kernel/yama:
7
8 - ptrace_scope
9
10 ==============================================================
11
12 ptrace_scope:
13
14 As Linux grows in popularity, it will become a larger target for
15 malware. One particularly troubling weakness of the Linux process
16 interfaces is that a single user is able to examine the memory and
17 running state of any of their processes. For example, if one application
18 (e.g. Pidgin) was compromised, it would be possible for an attacker to
19 attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
20 etc) to extract additional credentials and continue to expand the scope
21 of their attack without resorting to user-assisted phishing.
22
23 This is not a theoretical problem. SSH session hijacking
24 (http://www.storm.net.nz/projects/7) and arbitrary code injection
25 (http://c-skills.blogspot.com/2007/05/injectso.html) attacks already
26 exist and remain possible if ptrace is allowed to operate as before.
27 Since ptrace is not commonly used by non-developers and non-admins, system
28 builders should be allowed the option to disable this debugging system.
29
30 For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to
31 specifically disallow such ptrace attachment (e.g. ssh-agent), but many
32 do not. A more general solution is to only allow ptrace directly from a
33 parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
34 work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
35 still work as root).
36
37 In mode 1, software that has defined application-specific relationships
38 between a debugging process and its inferior (crash handlers, etc),
39 prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which
40 other process (and its descendents) are allowed to call PTRACE_ATTACH
41 against it. Only one such declared debugging process can exists for
42 each inferior at a time. For example, this is used by KDE, Chromium, and
43 Firefox's crash handlers, and by Wine for allowing only Wine processes
44 to ptrace each other. If a process wishes to entirely disable these ptrace
45 restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)
46 so that any otherwise allowed process (even those in external pid namespaces)
47 may attach.
48
49 These restrictions do not change how ptrace via PTRACE_TRACEME operates.
50
51 The sysctl settings are:
52
53 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
54     process running under the same uid, as long as it is dumpable (i.e.
55     did not transition uids, start privileged, or have called
56     prctl(PR_SET_DUMPABLE...) already).
57
58 1 - restricted ptrace: a process must have a predefined relationship
59     with the inferior it wants to call PTRACE_ATTACH on. By default,
60     this relationship is that of only its descendants when the above
61     classic criteria is also met. To change the relationship, an
62     inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
63     an allowed debugger PID to call PTRACE_ATTACH on the inferior.
64
65 2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
66     with PTRACE_ATTACH.
67
68 3 - no attach: no processes may use ptrace with PTRACE_ATTACH. Once set,
69     this sysctl cannot be changed to a lower value.
70
71 The original children-only logic was based on the restrictions in grsecurity.
72
73 ==============================================================