1Yama is a Linux Security Module that collects a number of system-wide DAC
   2security protections that are not handled by the core kernel itself. To
   3select it at boot time, specify "security=yama" (though this will disable
   4any other LSM).
   6Yama is controlled through sysctl in /proc/sys/kernel/yama:
   8- ptrace_scope
  14As Linux grows in popularity, it will become a larger target for
  15malware. One particularly troubling weakness of the Linux process
  16interfaces is that a single user is able to examine the memory and
  17running 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
  19attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
  20etc) to extract additional credentials and continue to expand the scope
  21of their attack without resorting to user-assisted phishing.
  23This is not a theoretical problem. SSH session hijacking
  24( and arbitrary code injection
  25( attacks already
  26exist and remain possible if ptrace is allowed to operate as before.
  27Since ptrace is not commonly used by non-developers and non-admins, system
  28builders should be allowed the option to disable this debugging system.
  30For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to
  31specifically disallow such ptrace attachment (e.g. ssh-agent), but many
  32do not. A more general solution is to only allow ptrace directly from a
  33parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
  34work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
  35still work as root).
  37In mode 1, software that has defined application-specific relationships
  38between a debugging process and its inferior (crash handlers, etc),
  39prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which
  40other process (and its descendents) are allowed to call PTRACE_ATTACH
  41against it. Only one such declared debugging process can exists for
  42each inferior at a time. For example, this is used by KDE, Chromium, and
  43Firefox's crash handlers, and by Wine for allowing only Wine processes
  44to ptrace each other. If a process wishes to entirely disable these ptrace
  45restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)
  46so that any otherwise allowed process (even those in external pid namespaces)
  47may attach.
  49The sysctl settings (writable only with CAP_SYS_PTRACE) are:
  510 - classic ptrace permissions: 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.
  571 - restricted ptrace: a process must have a predefined relationship
  58    with the inferior it wants to call PTRACE_ATTACH on. By default,
  59    this relationship is that of only its descendants when the above
  60    classic criteria is also met. To change the relationship, an
  61    inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
  62    an allowed debugger PID to call PTRACE_ATTACH on the inferior.
  63    Using PTRACE_TRACEME is unchanged.
  652 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
  66    with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.
  683 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via
  69    PTRACE_TRACEME. Once set, this sysctl value cannot be changed.
  71The original children-only logic was based on the restrictions in grsecurity.
  74 kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.