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

Make the module text and rodata read-only

Requires the kernel to be built with CONFIG_STRICT_MODULE_RWX=y, mapping module code read-only and module rodata non-executable.

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

CONFIG_STRICT_MODULE_RWX=y extends strict W^X (write-xor-execute) enforcement to loadable kernel modules: a module's executable code is mapped read-only and its read-only data non-executable. This denies attackers the ability to patch module code in place or execute module data as code, the same protection as STRICT_KERNEL_RWX but applied to the dynamically loaded module region, which is otherwise a soft target for rootkits.

What Pavois checks

Pavois reads the build configuration of the running kernel via /boot/config-$(uname -r) or /proc/config.gz and confirms CONFIG_STRICT_MODULE_RWX=y. Reading the booted kernel's effective config proves the module memory protections are compiled into the kernel actually in use, not just an installed default.

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

How to verify it is applied

grep '^CONFIG_STRICT_MODULE_RWX=' /boot/config-$(uname -r) || zcat /proc/config.gz | grep '^CONFIG_STRICT_MODULE_RWX='

Expected output: CONFIG_STRICT_MODULE_RWX=y.

Inspect & investigate

This is a static build-time protection with no routine log output. A violation (write to read-only module memory, or execution of module data) triggers a kernel oops/panic, inspect dmesg or journalctl -k. Confirm the option with the grep command above.

Remediation

No automated remediation is shipped: CONFIG_STRICT_MODULE_RWX is a compile-time kernel option and cannot be enabled at runtime. The fix is to boot a kernel built with it enabled, the stock distribution kernels for the supported OSes already do. For a custom kernel, set CONFIG_STRICT_MODULE_RWX=y and rebuild.

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

Without strict module RWX, loaded module code stays writable, so an attacker with a kernel write primitive can hijack a legitimate module to hide a rootkit. Precautions: the remedy is a kernel change requiring a reboot, schedule a maintenance window and keep a fallback boot entry. A few legacy or out-of-tree modules that self-modify their own code at load time may need updating; validate third-party modules (e.g. proprietary GPU drivers) after switching. Performance overhead is negligible.

Standards mapping

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