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

Restrict unprivileged access to the kernel syslog

Requires the kernel to be built with CONFIG_SECURITY_DMESG_RESTRICT=y so kernel.dmesg_restrict defaults to 1 and only privileged processes can read the kernel log.

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

Prevents unprivileged users from retrieving kernel addresses with dmesg. CONFIG_SECURITY_DMESG_RESTRICT sets the default of kernel.dmesg_restrict to 1, so only CAP_SYSLOG processes can read the kernel ring buffer. Kernel log lines routinely leak pointers, stack contents and addresses that defeat KASLR; restricting them denies a local attacker an easy information-disclosure stepping stone toward reliable exploitation.

What Pavois checks

Pavois reads the build options of the running kernel, grep '^CONFIG_SECURITY_DMESG_RESTRICT=' /boot/config-$(uname -r) or zcat /proc/config.gz, and requires y. Reading the live kernel's own config (keyed on uname -r) reflects exactly the booted kernel; note the build flag only sets the default, which kernel.dmesg_restrict can still override at runtime.

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_DMESG_RESTRICT=|PAVOIS_NO_KERNEL_CONFIG)'") do
  its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
  its('stdout') { should match(/^CONFIG_SECURITY_DMESG_RESTRICT=y$/) }
end

How to verify it is applied

Run grep '^CONFIG_SECURITY_DMESG_RESTRICT=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep CONFIG_SECURITY_DMESG_RESTRICT). Expected output:

CONFIG_SECURITY_DMESG_RESTRICT=y

Confirm the effective runtime value with sysctl kernel.dmesg_restrict, it should return kernel.dmesg_restrict = 1.

Inspect & investigate

No routine log entry. Check the live value with sysctl kernel.dmesg_restrict; an unprivileged dmesg attempt when restricted fails with Operation not permitted. Confirm the build flag with grep CONFIG_SECURITY_DMESG_RESTRICT /boot/config-$(uname -r).

Remediation

This is a kernel build-time option (it sets the default), so Pavois ships no automated harden step for the CONFIG_ symbol itself. It is satisfied by booting a distribution kernel compiled with CONFIG_SECURITY_DMESG_RESTRICT=y; a custom kernel must be rebuilt. The equivalent runtime control is the separate sysctl rule that sets kernel.dmesg_restrict = 1.

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

If absent (and the sysctl left at 0), any local user can read the kernel ring buffer and harvest addresses that undermine KASLR. Precautions: restricting dmesg can surprise monitoring agents, log shippers or diagnostic scripts that run unprivileged and parse dmesg; grant them CAP_SYSLOG or run them as root before enforcing, and verify your alerting still collects kernel messages so you do not lose visibility.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R15direct2.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) ↗