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