Restrict usage of ptrace to descendant processes
Sets kernel.yama.ptrace_scope=1 so a process can only ptrace its own descendants, blocking cross-process memory snooping.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
Unrestricted use of ptrace lets any process owned by a user inspect and manipulate the memory of every other process of that same user. A compromised binary could therefore attach to a running SSH client, browser or password manager and steal credentials, session keys or secrets without any extra privilege and without tricking the user. Setting kernel.yama.ptrace_scope=1 confines ptrace to the direct descendants of the tracing process (the classic debugger model), which neutralizes this whole class of process-injection and credential-theft attacks.
What Pavois checks
Pavois reads the live kernel value via kernel_parameter('kernel.yama.ptrace_scope'), i.e. what the running kernel actually enforces, and asserts it equals 1. Reading the running value catches the case where a drop-in in /etc/sysctl.d/ or a /etc/sysctl.conf line sets the key but it was never reloaded, or where a later drop-in overrides it. A file-based scanner that only greps sysctl.conf would report a value that is not the one the kernel is applying.
describe kernel_parameter('kernel.yama.ptrace_scope') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*kernel.yama.ptrace_scope[[:space:]]*=[[:space:]]*1([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run sysctl kernel.yama.ptrace_scope. Expected output:
kernel.yama.ptrace_scope = 1
Inspect & investigate
sysctl kernel.yama.ptrace_scopeshows the current value.cat /proc/sys/kernel/yama/ptrace_scopeis the raw kernel source of truth.- When a
ptracecall is denied, the kernel logs a line via the Yama LSM visible withdmesg | grep -i yama(e.g.ptrace of pid ... was attempted by ...).
Remediation
Pavois's harden plan uses the sysctl resource to set kernel.yama.ptrace_scope to 1. It writes the key into a Pavois-managed drop-in and reloads it so the value is active immediately and persistent across reboots. Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | kernel.yama.ptrace_scope |
|---|---|
| resource | sysctl |
| value | 1 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Functional impact is minimal on servers. The main caveat is debugging and tracing: tools such as gdb, strace, ltrace or crash-dumpers attaching to an already-running process you did not spawn will be denied unless run as root (CAP_SYS_PTRACE). Some monitoring/APM agents and container introspection tools rely on cross-process ptrace. Before applying, confirm no debugger-dependent agent needs unprivileged attach; if it does, run it with the required capability rather than disabling the protection. A value of 2 or 3 is even stricter but can break more tooling, so 1 is the recommended balance.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R11 | direct | 2.0 | high |
| CIS | 1.5.2, 1.5.7 | direct | per OS, see the benchmark table | high |
| NIST | SC-7(10) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.