← All rules
SOCLE-CLD-SYS-017// Kernel & network (sysctl)mediumeffective runtime

Enable Randomized Layout of Virtual Address Space

Sets kernel.randomize_va_space = 2 to enable full ASLR (stack, heap, mmap, VDSO and shared libraries are randomized).

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 5 standards

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

Address Space Layout Randomization (ASLR) makes it much harder for an attacker to predict where injected attack code lands in a process's address space, and harder to locate existing code to reuse via Return-Oriented Programming (ROP). Setting kernel.randomize_va_space = 2 enables full ASLR, randomizing the stack, heap (brk), mmap base, VDSO and shared libraries, significantly raising the cost of memory-corruption exploits.

What Pavois checks

Pavois reads the live kernel value with kernel_parameter('kernel.randomize_va_space') (equivalent to sysctl kernel.randomize_va_space), not a /etc/sysctl.d/*.conf line. ASLR is commonly weakened by a stray kernel.randomize_va_space = 0 left over from a debugging session or a low-quality container image; only reading the effective parameter detects that the running kernel actually has full randomization enabled.

describe kernel_parameter('kernel.randomize_va_space') do
  its('value') { should cmp 2 }
end
describe command("grep -hsE '^[[:space:]]*kernel.randomize_va_space[[:space:]]*=[[:space:]]*2([[: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/) }
end

How to verify it is applied

Run sysctl kernel.randomize_va_space. Expected output:

kernel.randomize_va_space = 2

Inspect & investigate

No dedicated log line. Confirm with sysctl kernel.randomize_va_space. You can observe ASLR at work: running cat /proc/self/maps twice should show different base addresses for the stack and libraries each time.

Remediation

Pavois's harden plan uses the sysctl resource to set kernel.randomize_va_space = 2, persists it in a Pavois-managed drop-in under /etc/sysctl.d/, and applies it live (no reboot). Apply it with pavois harden apply.

Pavois applies this with its own harden engine, the plan below, not a shell script:

keykernel.randomize_va_space
resourcesysctl
value2
pavois harden plan local

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

Impact & precautions

Risk if not applied: without full ASLR, memory addresses are predictable, making buffer-overflow and ROP exploits dramatically more reliable.

Precautions before applying:

  • ASLR is enabled by default and safe for virtually all software. Only niche workloads that hardcode or pin virtual addresses (some JITs, legacy emulators, certain HPC/database tuning, or debugging with disabled randomization) may misbehave; test such applications.
  • No boot or login lockout risk; the change is fully reversible at runtime.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R9direct2.0high
CIS1.5.1, 3.3.1.1, 1.5.8directper OS, see the benchmark tablehigh
NIST3.1.7, CM-6(a), SC-30, SC-30(2)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS3.3.1.1supporting4.0.1medium
DISA STIGUBTU-22-213020, UBTU-24-700310directper OS STIG releasehigh

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