Randomize the kernel memory sections
Requires the kernel to be built with CONFIG_RANDOMIZE_MEMORY=y so the physical memory mapping, vmalloc and vmemmap regions are placed at randomized virtual addresses.
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
This security feature makes exploits relying on predictable memory locations less reliable. CONFIG_RANDOMIZE_MEMORY extends KASLR to the physical memory mapping, vmalloc and vmemmap regions, so even if an attacker learns the kernel image base they still cannot predict where the direct map and page tables live, closing a class of attacks that target those fixed regions.
What Pavois checks
Pavois reads the build options of the running kernel, grep '^CONFIG_RANDOMIZE_MEMORY=' /boot/config-$(uname -r) or zcat /proc/config.gz, and requires the value y. Reading the live kernel's own config (keyed on uname -r) reflects exactly the kernel that is booted, including vendor or custom builds, which a package-name heuristic or a generic file cannot guarantee.
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_RANDOMIZE_MEMORY=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_RANDOMIZE_MEMORY=y$/) }
endHow to verify it is applied
Run grep '^CONFIG_RANDOMIZE_MEMORY=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep CONFIG_RANDOMIZE_MEMORY). Expected output:
CONFIG_RANDOMIZE_MEMORY=y
Inspect & investigate
There is no dedicated log entry. Confirm the setting via grep CONFIG_RANDOMIZE_MEMORY /boot/config-$(uname -r) and check cat /proc/cmdline, nokaslr disables both base and memory randomization even when compiled in.
Remediation
This is a kernel build-time option, so Pavois ships no automated harden step for it. It is satisfied by booting a distribution kernel compiled with CONFIG_RANDOMIZE_MEMORY=y (true for all current Debian/Ubuntu/RHEL x86-64 kernels) and ensuring nokaslr is absent from the boot parameters; a custom kernel must be rebuilt.
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
If absent, the kernel's physical map and page-table regions sit at predictable addresses, helping attackers turn leaks into reliable exploits. Precautions: this is bundled with KASLR in stock kernels and is low-risk to enable. The same caveats as KASLR apply, rare out-of-tree drivers, kexec/hibernation flows, or debuggers that assume fixed addresses may need testing on a non-production host before rollout.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R25 | 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.