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

Randomize the address of the kernel image (KASLR)

Requires the kernel to be built with CONFIG_RANDOMIZE_BASE=y so the kernel image is loaded at a randomized base address (KASLR).

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

An unpredictable kernel address makes it more difficult to succeed with exploits that rely on knowledge of the location of kernel code internals. Without KASLR (CONFIG_RANDOMIZE_BASE), the kernel is mapped at a fixed, well-known virtual address, so any information leak immediately hands an attacker reliable targets for ROP/return-to-kernel payloads and turns a memory-corruption bug into a dependable privilege-escalation exploit.

What Pavois checks

Pavois reads the build options of the running kernel, grep '^CONFIG_RANDOMIZE_BASE=' /boot/config-$(uname -r) or zcat /proc/config.gz, and requires the value y. Inspecting the live kernel's own config (keyed on uname -r) is more reliable than guessing from a package name or a generic config file: it reflects exactly the kernel that is booted, including vendor or custom builds.

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

How to verify it is applied

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

CONFIG_RANDOMIZE_BASE=y

You can also confirm KASLR is active at runtime: the kernel base in /proc/kallsyms differs across reboots (requires root to read non-zeroed addresses).

Inspect & investigate

There is no dedicated log entry. Confirm the setting via grep CONFIG_RANDOMIZE_BASE /boot/config-$(uname -r) and check the boot command line with cat /proc/cmdline, the presence of nokaslr there disables KASLR 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 that was compiled with CONFIG_RANDOMIZE_BASE=y (the case for all current Debian/Ubuntu/RHEL kernels). To enforce it you must install/boot a compliant kernel and ensure 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:

resourcekernel_build
pavois harden plan local

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

Impact & precautions

If absent, the kernel layout is deterministic and any pointer leak becomes a step toward reliable kernel exploitation. Precautions: enabling KASLR by switching to a distribution kernel is low-risk, but rare setups break, some out-of-tree drivers, certain hibernation/kexec flows, and a few legacy debuggers assume a fixed kernel base. Test a reboot on a non-production host first, and never add nokaslr to /proc/cmdline to work around such issues without understanding the security cost.

Standards mapping

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