OLD | NEW |
(Empty) | |
| 1 Yama is a Linux Security Module that collects a number of security |
| 2 protections that are not handled by the core kernel itself. To select |
| 3 it at boot time, specify "security=yama" (though this will disable any |
| 4 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 PTRACE is not commonly used by non-developers and non-admins, so 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 0 - classic PTRACE permissions: a process can PTRACE any other process |
| 82 running under the same uid, as long as it is dumpable (i.e. did not |
| 83 transition uids, start privileged, or have prctl(PR_SET_DUMPABLE...) |
| 84 called). |
| 85 |
| 86 1 - child-only PTRACE: a process can PTRACE only its descendants when |
| 87 the above classic criteria is also met. |
| 88 |
| 89 This protection is based on the restrictions in grsecurity. |
| 90 |
| 91 ============================================================== |
OLD | NEW |