Restrict Access to Kernel Message Buffer
Sets kernel.dmesg_restrict=1 so only privileged users (CAP_SYSLOG) can read the kernel ring buffer, hiding addresses that would aid a kernel exploit.
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
The kernel ring buffer (dmesg) often contains kernel pointers, memory addresses, module load details, and hardware information. An unprivileged user reading this can defeat KASLR and gather intelligence that helps craft a kernel exploit. Setting kernel.dmesg_restrict=1 requires CAP_SYSLOG to read the buffer, limiting access to root and reducing the information available to a local attacker.
What Pavois checks
Pavois reads the live kernel value via the kernel_parameter resource (equivalent to sysctl kernel.dmesg_restrict), not /etc/sysctl.conf or any *.conf drop-in. A value written to a file may never have loaded (typo, ordering, an overriding drop-in); reading the running kernel reflects whether unprivileged dmesg access is actually blocked right now.
describe kernel_parameter('kernel.dmesg_restrict') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*kernel.dmesg_restrict[[: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.dmesg_restrict, expected output kernel.dmesg_restrict = 1. As a non-root user, dmesg should then fail with Operation not permitted.
Inspect & investigate
Read the current value with sysctl kernel.dmesg_restrict or cat /proc/sys/kernel/dmesg_restrict. The kernel log itself remains accessible to root via dmesg or journalctl -k; non-root reads are simply denied with EPERM.
Remediation
Pavois's harden plan sets the sysctl key kernel.dmesg_restrict to 1, persisting it to a managed drop-in and applying it live so the running kernel and future boots both use it. Applied with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | kernel.dmesg_restrict |
|---|---|
| resource | sysctl |
| value | 1 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Low operational risk. The only change is that non-root users can no longer run dmesg; administrators and root-run monitoring are unaffected. Some unprivileged diagnostic or hardware-detection scripts that parse dmesg may need to run with elevated privileges or read journalctl -k as root instead. Reversible by resetting the key to 0.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | direct | 2.0 | high |
| NIST | 3.1.5, SI-11(a), SI-11(b) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| CIS | 1.5.5 | direct | per OS, see the benchmark table | high |
| DISA STIG | UBTU-22-213010, UBTU-24-600140 | direct | per OS STIG release | high |
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.