Sign kernel modules with SHA-512
Requires the running kernel to be built with CONFIG_MODULE_SIG_SHA512=y so module signatures use the strong SHA-512 hash.
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
The hash algorithm chosen for module signatures determines how hard it is to forge one. Weak hashes (SHA-1, MD5) are vulnerable to collision attacks that could let an attacker craft a counterfeit signature and load a malicious module. Selecting CONFIG_MODULE_SIG_SHA512=y uses SHA-512, a strong hash with no practical collision attack, making forged module signatures infeasible.
What Pavois checks
Pavois reads the build-time config of the running kernel via /boot/config-$(uname -r), falling back to /proc/config.gz, so the result reflects the booted kernel rather than a static file. Pavois expects CONFIG_MODULE_SIG_SHA512=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_SHA512=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_MODULE_SIG_SHA512=y$/) }
endHow to verify it is applied
Run grep '^CONFIG_MODULE_SIG_SHA512=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep '^CONFIG_MODULE_SIG_SHA512='). Expected output: CONFIG_MODULE_SIG_SHA512=y.
Inspect & investigate
modinfo <module> shows the signature hash algorithm in its sig_hashalgo field (expected sha512). dmesg | grep -i module and journalctl -k show any signature errors at load time.
Remediation
No automated remediation: CONFIG_MODULE_SIG_SHA512 is a kernel build-time option that selects the signing hash at compile time and cannot be changed at runtime. Use a distribution kernel that signs modules with SHA-512, or rebuild 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
Using a weak signing hash leaves the door open to forged module signatures, undermining the whole module-signing chain. There is no runtime breakage risk from this check itself; it is a build-time property of the kernel. When selecting kernels, prefer distribution kernels (which already use SHA-256/SHA-512) and ensure all modules are re-signed with the matching hash if you rebuild, so enforcement does not reject them.
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.