Disable /dev/kmem virtual device support
Requires the kernel to be built without CONFIG_DEVKMEM, removing the /dev/kmem interface that exposes kernel virtual memory.
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 /dev/kmem device is rarely used, but can be used for certain kind of kernel debugging operations.
What Pavois checks
Pavois reads the effective build flag of the running kernel via /boot/config-$(uname -r) or /proc/config.gz, keyed on $(uname -r). The control asserts the flag is not =y, reflecting the actually booted image rather than a stray .config a fixed-path file scan could match.
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_DEVKMEM=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should_not match(/^CONFIG_DEVKMEM=y$/) }
endHow to verify it is applied
Run grep '^CONFIG_DEVKMEM=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep '^CONFIG_DEVKMEM='). Expected: no output, or # CONFIG_DEVKMEM is not set. A line CONFIG_DEVKMEM=y is a failure. You can also confirm the device is absent with ls -l /dev/kmem (should report no such file).
Inspect & investigate
This is a build-time absence with no runtime logging. Verify state directly with zcat /proc/config.gz | grep DEVKMEM and ls /dev/kmem. Any process attempting to open a non-existent /dev/kmem simply gets ENOENT.
Remediation
No automated remediation is shipped: a kernel build option cannot be unset by editing a file. Apply it manually by installing and booting a kernel compiled without CONFIG_DEVKMEM (the default on current distributions).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| resource | kernel_build |
|---|
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
/dev/kmem is a character device giving direct read/write access to the kernel's virtual address space. Any process able to open it (root, or via a privilege bug) can read secrets, patch kernel code, or install a rootkit with no module loading and no trace in the module list. It is legacy debugging machinery almost nothing legitimately uses. Compiling it out removes a powerful post-exploitation primitive. This is a build-time option (the inverse of the others: it must be absent), changeable only by booting a kernel compiled without it. Modern distribution kernels already disable it, so this rule usually passes. Precautions: the only software that ever needed /dev/kmem is ancient (some old debuggers, original lrmi); confirm nothing on the host depends on it before swapping kernels. No reboot risk beyond a normal kernel swap.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R15 | direct | 2.0 | 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.