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 - protected_sticky_symlinks
   9 - protected_nonaccess_hardlinks
  10 - ptrace_scope
  11
  12 ==============================================================
  13
  14 protected_sticky_symlinks:
  15
  16 A long-standing class of security issues is the symlink-based
  17 time-of-check-time-of-use race, most commonly seen in world-writable
  18 directories like /tmp. The common method of exploitation of this flaw
  19 is to cross privilege boundaries when following a given symlink (i.e. a
  20 root process follows a symlink belonging to another user). For a likely
  21 incomplete list of hundreds of examples across the years, please see:
  22 http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
  23
  24 When set to "0", symlink following behavior is unrestricted.
  25
  26 When set to "1" symlinks are permitted to be followed only when outside
  27 a sticky world-writable directory, or when the uid of the symlink and
  28 follower match, or when the directory owner matches the symlink's owner.
  29
  30 This protection is based on the restrictions in Openwall and grsecurity.
  31
  32 ==============================================================
  33
  34 protected_nonaccess_hardlinks:
  35
  36 Hardlinks can be abused in a similar fashion to symlinks in sticky
  37 world-writable directories, but their weakness is not limited to
  38 just that scenario. For example, if /etc and /home are on the same
  39 partition, a regular user can create a hardlink to /etc/shadow in their
  40 home directory. While it retains the original owner and permissions,
  41 it is possible for privileged programs that are otherwise symlink-safe
  42 to mistakenly access the file through its hardlink. Additionally, a very
  43 minor untraceable quota-bypassing local denial of service is possible by
  44 an attacker exhausting disk space by filling a world-writable directory
  45 with hardlinks.
  46
  47 When set to "0", hardlink creation behavior is unrestricted.
  48
  49 When set to "1", hardlinks cannot be created to files that a given user
  50 would be unable to read and write originally, or are otherwise sensitive.
  51
  52 This protection is based on the restrictions in Openwall and grsecurity.
  53
  54 ==============================================================
  55
  56 ptrace_scope:
  57
  58 As Linux grows in popularity, it will become a larger target for
  59 malware. One particularly troubling weakness of the Linux process
  60 interfaces is that a single user is able to examine the memory and
  61 running state of any of their processes. For example, if one application
  62 (e.g. Pidgin) was compromised, it would be possible for an attacker to
  63 attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
  64 etc) to extract additional credentials and continue to expand the scope
  65 of their attack without resorting to user-assisted phishing.
  66
  67 This is not a theoretical problem. SSH session hijacking
  68 (http://www.storm.net.nz/projects/7) and arbitrary code injection
  69 (http://c-skills.blogspot.com/2007/05/injectso.html) attacks already
  70 exist and remain possible if ptrace is allowed to operate as before.
  71 Since ptrace is not commonly used by non-developers and non-admins, system
  72 builders should be allowed the option to disable this debugging system.
  73
  74 For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to
  75 specifically disallow such ptrace attachment (e.g. ssh-agent), but many
  76 do not. A more general solution is to only allow ptrace directly from a
  77 parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
  78 work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
  79 still work as root).
  80
  81 For software that has defined application-specific relationships
  82 between a debugging process and its inferior (crash handlers, etc),
  83 prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which
  84 other process (and its descendents) are allowed to call PTRACE_ATTACH
  85 against it. Only one such declared debugging process can exists for
  86 each inferior at a time. For example, this is used by KDE, Chromium, and
  87 Firefox's crash handlers, and by Wine for allowing only Wine processes
  88 to ptrace each other. If a process wishes to entirely disable these ptrace
  89 restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)
  90 so that any otherwise allowed process (even those in external pid namespaces)
  91 may attach.
  92
  93 The sysctl settings are:
  94
  95 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
  96     process running under the same uid, as long as it is dumpable (i.e.
  97     did not transition uids, start privileged, or have called
  98     prctl(PR_SET_DUMPABLE...) already).
  99
 100 1 - restricted ptrace: a process must have a predefined relationship
 101     with the inferior it wants to call PTRACE_ATTACH on. By default,
 102     this relationship is that of only its descendants when the above
 103     classic criteria is also met. To change the relationship, an
 104     inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
 105     an allowed debugger PID to call PTRACE_ATTACH on the inferior.
 106
 107 The original children-only logic was based on the restrictions in grsecurity.
 108
 109 ==============================================================