Make the auditd Configuration Immutable
Ensures the audit subsystem is locked with -e 2 so the loaded ruleset is immutable until the next reboot and cannot be changed at runtime.
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
Making the audit configuration immutable prevents both accidental and malicious modification of the audit rules at runtime. An attacker who gains root could otherwise disable auditing (auditctl -e 0) or delete rules to operate undetected. With -e 2, any change requires a reboot, which itself is an auditable, noticeable event. The trade-off: legitimate rule changes also require a reboot.
What Pavois checks
Pavois runs auditctl -s and checks that the kernel reports enabled 2. Reading the live audit status beats inspecting the trailing -e 2 line in a rules file: the immutable flag is only effective once the kernel has applied it. A file containing -e 2 that was never loaded leaves the system mutable; auditctl -s shows the real, enforced state.
describe command('auditctl -s') do
its('stdout') { should match(/enabled[[:space:]]+2/) }
endHow to verify it is applied
Run auditctl -s | grep enabled. The expected output is enabled 2 (1 = enabled but mutable, 0 = disabled). Once immutable, auditctl -e 0 is refused until reboot.
Inspect & investigate
auditctl -s reports the live status (enabled, flag, backlog). Service messages appear via journalctl -u auditd, and any attempt to change rules while immutable is denied (surfaced to the calling process as an error).
Remediation
Pavois's harden plan uses the audit_ruleset resource to append the -e 2 directive as the last line of the loaded ruleset (it must come last, after all rules). Because immutability only takes hold on the next boot, a reboot is required. 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
After applying, the audit ruleset is frozen: you cannot add, remove or reload rules without rebooting. Apply this rule last, only after all other audit rules are in place and verified, otherwise you lock in an incomplete ruleset and must reboot to fix it. It does not affect logins or services. On systems needing frequent audit-rule changes, weigh the operational cost of the mandatory reboot.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | high |
| CIS | 10.3.2, 6.2.3.20, 6.3.3.33, 6.3.3.20, 6.3.3.21 | direct | per OS, see the benchmark table | high |
| NIST | 3.3.1, AC-6(9), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 10.3.2 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-24-909000 | direct | per OS STIG release | 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.