doc: ReSTify Yama.txt

====

Yama

====

Yama is a Linux Security Module that collects system-wide DAC security

protections that are not handled by the core kernel itself. This is

selectable at build-time with CONFIG_SECURITY_YAMA, and can be controlled

at run-time through sysctls in /proc/sys/kernel/yama:

- ptrace_scope

selectable at build-time with ``CONFIG_SECURITY_YAMA``, and can be controlled

at run-time through sysctls in ``/proc/sys/kernel/yama``:

==============================================================

ptrace_scope:

ptrace_scope

============

As Linux grows in popularity, it will become a larger target for

malware. One particularly troubling weakness of the Linux process

Since ptrace is not commonly used by non-developers and non-admins, system

builders should be allowed the option to disable this debugging system.

For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to

For a solution, some applications use ``prctl(PR_SET_DUMPABLE, ...)`` to

specifically disallow such ptrace attachment (e.g. ssh-agent), but many

do not. A more general solution is to only allow ptrace directly from a

parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still

work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"

work), or with ``CAP_SYS_PTRACE`` (i.e. "gdb --pid=PID", and "strace -p PID"

still work as root).

In mode 1, software that has defined application-specific relationships

between a debugging process and its inferior (crash handlers, etc),

prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which

other process (and its descendants) are allowed to call PTRACE_ATTACH

``prctl(PR_SET_PTRACER, pid, ...)`` can be used. An inferior can declare which

other process (and its descendants) are allowed to call ``PTRACE_ATTACH``

against it. Only one such declared debugging process can exists for

each inferior at a time. For example, this is used by KDE, Chromium, and

Firefox's crash handlers, and by Wine for allowing only Wine processes

to ptrace each other. If a process wishes to entirely disable these ptrace

restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)

restrictions, it can call ``prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)``

so that any otherwise allowed process (even those in external pid namespaces)

may attach.

The sysctl settings (writable only with CAP_SYS_PTRACE) are:

The sysctl settings (writable only with ``CAP_SYS_PTRACE``) are:

0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other

0 - classic ptrace permissions:

    a process can ``PTRACE_ATTACH`` to any other

    process running under the same uid, as long as it is dumpable (i.e.

    did not transition uids, start privileged, or have called

    prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is

    ``prctl(PR_SET_DUMPABLE...)`` already). Similarly, ``PTRACE_TRACEME`` is

    unchanged.

1 - restricted ptrace: a process must have a predefined relationship

    with the inferior it wants to call PTRACE_ATTACH on. By default,

1 - restricted ptrace:

    a process must have a predefined relationship

    with the inferior it wants to call ``PTRACE_ATTACH`` on. By default,

    this relationship is that of only its descendants when the above

    classic criteria is also met. To change the relationship, an

    inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare

    an allowed debugger PID to call PTRACE_ATTACH on the inferior.

    Using PTRACE_TRACEME is unchanged.

    inferior can call ``prctl(PR_SET_PTRACER, debugger, ...)`` to declare

    an allowed debugger PID to call ``PTRACE_ATTACH`` on the inferior.

    Using ``PTRACE_TRACEME`` is unchanged.

2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace

    with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.

2 - admin-only attach:

    only processes with ``CAP_SYS_PTRACE`` may use ptrace

    with ``PTRACE_ATTACH``, or through children calling ``PTRACE_TRACEME``.

3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via

    PTRACE_TRACEME. Once set, this sysctl value cannot be changed.

3 - no attach:

    no processes may use ptrace with ``PTRACE_ATTACH`` nor via

    ``PTRACE_TRACEME``. Once set, this sysctl value cannot be changed.

The original children-only logic was based on the restrictions in grsecurity.

==============================================================

   apparmor

   SELinux

   tomoyo

   Yama

	- this file.

Smack.txt

	- documentation on the Smack Linux Security Module.

Yama.txt

	- documentation on the Yama Linux Security Module.

keys-ecryptfs.txt

	- description of the encryption keys for the ecryptfs filesystem.

keys-request-key.txt

T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git yama/tip

S:	Supported

F:	security/yama/

F:	Documentation/admin-guide/LSM/Yama.rst

SENSABLE PHANTOM

M:	Jiri Slaby <jirislaby@gmail.com>

	  system-wide security settings beyond regular Linux discretionary

	  access controls. Currently available is ptrace scope restriction.

	  Like capabilities, this security module stacks with other LSMs.

	  Further information can be found in Documentation/security/Yama.txt.

	  Further information can be found in

	  Documentation/admin-guide/LSM/Yama.rst.

	  If you are unsure how to answer this question, answer N.