← All rules
SOCLE-CLD-SYS-011// Kernel & network (sysctl)mediumeffective runtime

Restrict Exposed Kernel Pointer Addresses Access

Sets kernel.kptr_restrict = 2 so kernel pointer addresses are hidden (printed as 0) from every user, including those with CAP_SYSLOG.

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 3 standards

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

Exposing kernel pointers (through procfs or seq_printf()) leaks the addresses of kernel writeable structures, which may contain function pointers. If a write vulnerability in the kernel allows tampering with one of these structures, the leaked addresses make the kernel far easier to compromise reliably (defeating KASLR). Setting kptr_restrict = 2 replaces kernel pointers printed via these interfaces with 0 for all users, regardless of CAP_SYSLOG.

What Pavois checks

Pavois reads the live kernel value with kernel_parameter('kernel.kptr_restrict') (equivalent to sysctl kernel.kptr_restrict), not a line in /etc/sysctl.conf or /etc/sysctl.d/*.conf. A file may declare 2 while the running kernel is still at 0 or 1 because a later drop-in overrode it, the file was never applied, or a sysctl -w changed it at runtime. Auditing the effective parameter is the only reliable proof of what the kernel enforces now.

describe kernel_parameter('kernel.kptr_restrict') do
  its('value') { should cmp 2 }
end
describe command("grep -hsE '^[[:space:]]*kernel.kptr_restrict[[:space:]]*=[[:space:]]*2([[: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/) }
end

How to verify it is applied

Run sysctl kernel.kptr_restrict. Expected output:

kernel.kptr_restrict = 2

Inspect & investigate

No log entry is produced by this setting. Confirm it directly with sysctl kernel.kptr_restrict. You can observe the effect by checking that pointers are masked, e.g. cat /proc/kallsyms | head should show addresses as 0000000000000000.

Remediation

Pavois's harden plan uses the sysctl resource to set kernel.kptr_restrict = 2, writes it to a Pavois-managed drop-in under /etc/sysctl.d/ for persistence, and applies it live (no reboot). Apply it with pavois harden apply.

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

keykernel.kptr_restrict
resourcesysctl
value2
pavois harden plan local

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

Impact & precautions

Risk if not applied: kernel pointer addresses leak through /proc, weakening KASLR and giving an attacker the precise targets needed to turn a write primitive into reliable kernel code execution.

Precautions before applying:

  • Value 2 hides pointers even from privileged tools. Some performance/debugging tooling (perf, eBPF tracers, systemtap, certain profilers) may show 0x0 addresses or lose symbol resolution. On dedicated profiling hosts you may prefer 1; for hardened production servers 2 is the recommended value.
  • The change is harmless to applications and fully reversible at runtime, so no lockout risk.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R9direct2.0high
NISTCM-6(a), SC-30, SC-30(2), SC-30(5)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
CIS1.5.6directper OS, see the benchmark tablehigh

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