← All rules
SOCLE-CLD-KRN-069// Kernel buildmediumeffective runtime

Enable Yama support

Requires the kernel to be built with the Yama LSM (CONFIG_SECURITY_YAMA=y), which enables ptrace scope restrictions.

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.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

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 compromised process attach to and inspect the memory of other processes owned by the same user. The Yama LSM (CONFIG_SECURITY_YAMA=y) is the kernel building block that makes the kernel.yama.ptrace_scope restriction available, blocking a hijacked binary (e.g. a browser or mail client) from scraping credentials, SSH keys or session tokens out of sibling processes.

What Pavois checks

Pavois reads the kernel build configuration of the running kernel, via /boot/config-$(uname -r) or the in-kernel /proc/config.gz, and confirms CONFIG_SECURITY_YAMA=y. Querying the live kernel (not a packaged default config) guarantees that the kernel actually booted with Yama compiled in, a kernel installed but not yet booted, or an out-of-tree build, would otherwise give a false sense of compliance.

describe command("C=/boot/config-$(uname -r); if [ -r \"$C\" ]; then cat \"$C\"; elif zcat /proc/config.gz 2>/dev/null | head -1 | grep -q .; then zcat /proc/config.gz; else echo PAVOIS_NO_KERNEL_CONFIG; fi | grep -E '^(CONFIG_SECURITY_YAMA=|PAVOIS_NO_KERNEL_CONFIG)'") do
  its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
  its('stdout') { should match(/^CONFIG_SECURITY_YAMA=y$/) }
end

How to verify it is applied

Confirm the option is compiled in:

grep '^CONFIG_SECURITY_YAMA=' /boot/config-$(uname -r) || zcat /proc/config.gz | grep '^CONFIG_SECURITY_YAMA='

Expected output: CONFIG_SECURITY_YAMA=y. You can also confirm the runtime knob it provides exists: sysctl kernel.yama.ptrace_scope.

Inspect & investigate

Yama-blocked ptrace attempts are logged by the kernel. Inspect dmesg or journalctl -k for messages such as ptrace of pid ... was attempted by .... The effective restriction level is read with sysctl kernel.yama.ptrace_scope.

Remediation

No automated remediation is shipped: CONFIG_SECURITY_YAMA is a compile-time kernel option, so it cannot be toggled at runtime. The fix is to run a kernel built with Yama enabled. The stock distribution kernels for the supported OSes already ship it, so the remedy is normally to install or boot the vendor kernel rather than a custom one. If you build your own kernel, set CONFIG_SECURITY_YAMA=y and rebuild.

Pavois applies this with its own harden engine, the plan below, not a shell script:

resourcekernel_build
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Without Yama, the kernel.yama.ptrace_scope restriction is unavailable, leaving every user process able to ptrace its siblings, a major lateral-credential-theft vector. Precautions: switching kernels requires a reboot, so schedule a maintenance window and keep the previous kernel entry in GRUB as a fallback. Some debuggers (gdb), profilers (perf) and crash-handling tools rely on ptrace; with Yama enabled and ptrace_scope set high they may need to run as root or use CAP_SYS_PTRACE. Validate your debugging workflows after the change.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R20direct2.0high

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.

Sources & references

Official standards

ANSSI-BP-028 (2.0) ↗