Documentation/admin-guide/LSM/Yama.rst

   1 ====
   2 Yama
   3 ====
   4
   5 Yama is a Linux Security Module that collects system-wide DAC security
   6 protections that are not handled by the core kernel itself. This is
   7 selectable at build-time with ``CONFIG_SECURITY_YAMA``, and can be controlled
   8 at run-time through sysctls in ``/proc/sys/kernel/yama``:
   9
  10 ptrace_scope
  11 ============
  12
  13 As Linux grows in popularity, it will become a larger target for
  14 malware. One particularly troubling weakness of the Linux process
  15 interfaces is that a single user is able to examine the memory and
  16 running 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
  18 attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
  19 etc) to extract additional credentials and continue to expand the scope
  20 of their attack without resorting to user-assisted phishing.
  21
  22 This 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
  25 exist and remain possible if ptrace is allowed to operate as before.
  26 Since ptrace is not commonly used by non-developers and non-admins, system
  27 builders should be allowed the option to disable this debugging system.
  28
  29 For a solution, some applications use ``prctl(PR_SET_DUMPABLE, ...)`` to
  30 specifically disallow such ptrace attachment (e.g. ssh-agent), but many
  31 do not. A more general solution is to only allow ptrace directly from a
  32 parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
  33 work), or with ``CAP_SYS_PTRACE`` (i.e. "gdb --pid=PID", and "strace -p PID"
  34 still work as root).
  35
  36 In mode 1, software that has defined application-specific relationships
  37 between a debugging process and its inferior (crash handlers, etc),
  38 ``prctl(PR_SET_PTRACER, pid, ...)`` can be used. An inferior can declare which
  39 other process (and its descendants) are allowed to call ``PTRACE_ATTACH``
  40 against it. Only one such declared debugging process can exists for
  41 each inferior at a time. For example, this is used by KDE, Chromium, and
  42 Firefox's crash handlers, and by Wine for allowing only Wine processes
  43 to ptrace each other. If a process wishes to entirely disable these ptrace
  44 restrictions, it can call ``prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)``
  45 so that any otherwise allowed process (even those in external pid namespaces)
  46 may attach.
  47
  48 The sysctl settings (writable only with ``CAP_SYS_PTRACE``) are:
  49
  50 0 - 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
  57 1 - 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
  66 2 - admin-only attach:
  67     only processes with ``CAP_SYS_PTRACE`` may use ptrace
  68     with ``PTRACE_ATTACH``, or through children calling ``PTRACE_TRACEME``.
  69
  70 3 - 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
  74 The original children-only logic was based on the restrictions in grsecurity.