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

Require modules to be validly signed

Requires the running kernel to be built with CONFIG_MODULE_SIG_FORCE=y so it rejects any module that is unsigned or signed with an untrusted key.

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_MODULE_SIG only makes the kernel able to verify signatures; without CONFIG_MODULE_SIG_FORCE=y it still loads unsigned modules (it merely taints the kernel). Enforcement makes the kernel refuse any module that is unsigned or signed with an unknown key, closing the door an attacker would otherwise use to load arbitrary ring-0 code. This is the option that turns module signing from advisory into mandatory.

What Pavois checks

Pavois reads the build-time config of the running kernel via /boot/config-$(uname -r) with /proc/config.gz as a fallback, so the result reflects the kernel actually booted rather than a static file. Pavois expects CONFIG_MODULE_SIG_FORCE=y.

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

How to verify it is applied

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

Inspect & investigate

Check dmesg | grep -i module and journalctl -k for rejections such as Loading of unsigned module is rejected. Use cat /proc/sys/kernel/tainted to see whether an unsigned module has tainted the kernel (bit 13, value 8192).

Remediation

No automated remediation: CONFIG_MODULE_SIG_FORCE is a kernel build-time option that cannot be toggled at runtime. It requires a kernel compiled with enforcement enabled (or, on a Secure Boot system with the lockdown LSM, signature enforcement can also be imposed by booting in lockdown=integrity/confidentiality mode). Apply manually; pavois harden apply cannot change a compiled-in setting.

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 enforcement, an attacker who can drop a module file can run code in the kernel undetected. The main risk when enabling enforcement is breaking legitimate out-of-tree modules: proprietary GPU drivers (NVIDIA), VirtualBox, DKMS-built modules and some kernel debug tools will fail to load if they are not signed with a trusted key. Before enforcing, sign every needed module (or enroll the key via MOK under Secure Boot), test in a non-production boot, and keep console/recovery access so a failed module load does not lock you out of required hardware.

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) ↗