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