0001 ====
0002 Yama
0003 ====
0004
0005 Yama is a Linux Security Module that collects system-wide DAC security
0006 protections that are not handled by the core kernel itself. This is
0007 selectable at build-time with ``CONFIG_SECURITY_YAMA``, and can be controlled
0008 at run-time through sysctls in ``/proc/sys/kernel/yama``:
0009
0010 ptrace_scope
0011 ============
0012
0013 As Linux grows in popularity, it will become a larger target for
0014 malware. One particularly troubling weakness of the Linux process
0015 interfaces is that a single user is able to examine the memory and
0016 running state of any of their processes. For example, if one application
0017 (e.g. Pidgin) was compromised, it would be possible for an attacker to
0018 attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
0019 etc) to extract additional credentials and continue to expand the scope
0020 of their attack without resorting to user-assisted phishing.
0021
0022 This is not a theoretical problem. `SSH session hijacking
0023 <https://www.blackhat.com/presentations/bh-usa-05/bh-us-05-boileau.pdf>`_
0024 and `arbitrary code injection
0025 <https://c-skills.blogspot.com/2007/05/injectso.html>`_ attacks already
0026 exist and remain possible if ptrace is allowed to operate as before.
0027 Since ptrace is not commonly used by non-developers and non-admins, system
0028 builders should be allowed the option to disable this debugging system.
0029
0030 For a solution, some applications use ``prctl(PR_SET_DUMPABLE, ...)`` to
0031 specifically disallow such ptrace attachment (e.g. ssh-agent), but many
0032 do not. A more general solution is to only allow ptrace directly from a
0033 parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
0034 work), or with ``CAP_SYS_PTRACE`` (i.e. "gdb --pid=PID", and "strace -p PID"
0035 still work as root).
0036
0037 In mode 1, software that has defined application-specific relationships
0038 between a debugging process and its inferior (crash handlers, etc),
0039 ``prctl(PR_SET_PTRACER, pid, ...)`` can be used. An inferior can declare which
0040 other process (and its descendants) are allowed to call ``PTRACE_ATTACH``
0041 against it. Only one such declared debugging process can exists for
0042 each inferior at a time. For example, this is used by KDE, Chromium, and
0043 Firefox's crash handlers, and by Wine for allowing only Wine processes
0044 to ptrace each other. If a process wishes to entirely disable these ptrace
0045 restrictions, it can call ``prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)``
0046 so that any otherwise allowed process (even those in external pid namespaces)
0047 may attach.
0048
0049 The sysctl settings (writable only with ``CAP_SYS_PTRACE``) are:
0050
0051 0 - classic ptrace permissions:
0052 a process can ``PTRACE_ATTACH`` to any other
0053 process running under the same uid, as long as it is dumpable (i.e.
0054 did not transition uids, start privileged, or have called
0055 ``prctl(PR_SET_DUMPABLE...)`` already). Similarly, ``PTRACE_TRACEME`` is
0056 unchanged.
0057
0058 1 - restricted ptrace:
0059 a process must have a predefined relationship
0060 with the inferior it wants to call ``PTRACE_ATTACH`` on. By default,
0061 this relationship is that of only its descendants when the above
0062 classic criteria is also met. To change the relationship, an
0063 inferior can call ``prctl(PR_SET_PTRACER, debugger, ...)`` to declare
0064 an allowed debugger PID to call ``PTRACE_ATTACH`` on the inferior.
0065 Using ``PTRACE_TRACEME`` is unchanged.
0066
0067 2 - admin-only attach:
0068 only processes with ``CAP_SYS_PTRACE`` may use ptrace, either with
0069 ``PTRACE_ATTACH`` or through children calling ``PTRACE_TRACEME``.
0070
0071 3 - no attach:
0072 no processes may use ptrace with ``PTRACE_ATTACH`` nor via
0073 ``PTRACE_TRACEME``. Once set, this sysctl value cannot be changed.
0074
0075 The original children-only logic was based on the restrictions in grsecurity.
