| # When yama is enabled in the kernel it might be used to filter any user |
| # space access which requires PTRACE_MODE_ATTACH like ptrace attach, access |
| # to /proc/PID/{mem,personality,stack,syscall}, and the syscalls |
| # process_vm_readv and process_vm_writev which are used for interprocess |
| # services, communication and introspection (like synchronisation, signaling, |
| # debugging, tracing and profiling) of processes. |
| # |
| # Usage of ptrace attach is restricted by normal user permissions. Normal |
| # unprivileged processes cannot interact through ptrace with processes |
| # that they cannot send signals to or processes that are running set-uid |
| # or set-gid. |
| # |
| # yama ptrace scope can be used to reduce these permissions even more. |
| # This should normally not be done because it will break various programs |
| # relying on the default ptrace security restrictions. But can be used |
| # if you don't have any other way to separate processes in their own |
| # domains. A different way to restrict ptrace is to set the selinux |
| # deny_ptrace boolean. Both mechanisms will break some programs relying |
| # on the ptrace system call and might force users to elevate their |
| # privileges to root to do their work. |
| # |
| # For more information see Documentation/security/Yama.txt in the kernel |
| # sources. Which also describes the defaults when CONFIG_SECURITY_YAMA |
| # is enabled in a kernel build (currently 1 for ptrace_scope). |
| # |
| # This runtime kernel parameter can be set to the following options: |
| # (Note that setting this to anything except zero will break programs!) |
| # |
| # 0 - Default attach security permissions. |
| # 1 - Restricted attach. Only child processes plus normal permissions. |
| # 2 - Admin-only attach. Only executables with CAP_SYS_PTRACE. |
| # 3 - No attach. No process may call ptrace at all. Irrevocable. |
| # |
| kernel.yama.ptrace_scope = 0 |
| |
