Ensure auditd Collects Information on Kernel Module Unloading - create_module
Ensures auditd has an active rule tagged modules that records kernel-module syscalls (init_module, finit_module, delete_module, create_module) and use of modprobe/insmod/rmmod.
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
Loading or unloading kernel modules can alter kernel behavior and inject malicious code (rootkits) into kernel space. Keeping an audit trail of every module introduced into or removed from the kernel is essential to detect and investigate such tampering. Without it, a kernel-level compromise can occur with no record.
What Pavois checks
Pavois runs auditctl -l and checks for a loaded rule carrying the modules key. Reading the live kernel ruleset beats parsing /etc/audit/rules.d/*.rules: a rule present in a file but not loaded gives false assurance. auditctl -l reflects only what the kernel enforces right now.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)modules\b/) }
end
describe command("grep -rhwsE 'modules' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run auditctl -l | grep modules. You should see syscall rules such as -a always,exit -F arch=b64 -S init_module,finit_module,delete_module,create_module -F auid>=1000 -F auid!=unset -k modules. Empty output means the rule is not loaded.
Inspect & investigate
Triggered events land in /var/log/audit/audit.log. Search with grep 'key="modules"' /var/log/audit/audit.log (prefer grep over ausearch -k modules, which can wrongly report no matches).
Remediation
Pavois's harden plan uses the audit_ruleset resource to write the kernel-module syscall and command rules into /etc/audit/rules.d/, then reloads auditd. Because the audit config may be immutable, a reboot is required to fully apply. Run pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without this rule, rootkit-style module loading goes unrecorded. The rule is log-only and cannot block module operations, so it breaks nothing. Precautions: legitimate module activity (boot, hardware hotplug, container runtimes) generates events, size audit.log rotation and space_left_action so a full disk does not halt the host when auditd is set to halt.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | high |
| CIS | 6.3.3.29, 6.3.3.30, 6.3.3.31, 6.3.3.19 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.7 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.