Enable module signature verification
Requires the running kernel to be built with CONFIG_MODULE_SIG=y so it can verify cryptographic signatures on loadable modules.
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
Without CONFIG_MODULE_SIG=y, the kernel accepts any .ko module regardless of origin. An attacker with the ability to load a module (root, a vulnerable setuid path, or a supply-chain swap of a module file) can inject arbitrary code straight into ring 0, bypassing every userspace protection. Module signing makes the kernel cryptographically verify each module against a trusted key, so only modules built and signed by a trusted party can be loaded.
What Pavois checks
Pavois reads the build-time kernel configuration of the running kernel, /boot/config-$(uname -r) and, as a fallback, /proc/config.gz exposed by the live kernel. Using uname -r and /proc/config.gz ties the check to the kernel that is actually booted, not to a config file that might describe a different or future kernel. Pavois expects CONFIG_MODULE_SIG=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=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_MODULE_SIG=y$/) }
endHow to verify it is applied
Run grep '^CONFIG_MODULE_SIG=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep '^CONFIG_MODULE_SIG='). Expected output: CONFIG_MODULE_SIG=y.
Inspect & investigate
Kernel module activity is visible via dmesg | grep -i module and journalctl -k. A rejected unsigned module shows messages like Loading of unsigned module is rejected. List currently loaded modules with lsmod.
Remediation
No automated remediation is available: this is a kernel build-time option. It cannot be toggled at runtime, it requires a kernel compiled with CONFIG_MODULE_SIG=y. Use a distribution kernel that already ships signed modules (most do), or rebuild the kernel with this option. 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:
| 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 will load malicious or tampered modules without complaint, giving an attacker full ring-0 control. Precautions before changing: enabling signature enforcement (CONFIG_MODULE_SIG_FORCE) on a system with third-party out-of-tree modules (proprietary GPU drivers, VirtualBox, DKMS) can prevent those modules from loading and may break hardware or boot. Verify all required modules are signed by a trusted key before enforcing, and keep console access in case a module fails to load.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R18 | 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.