Enable auditd Service
Enables and starts the auditd service so kernel audit records are persistently written and individual user actions are traceable.
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
auditd is the user-space daemon that records the kernel's audit events to disk. Without it running, security-relevant events, logins, privilege use, file access, configuration changes, are not captured, making it impossible to reconstruct, correlate, or investigate an incident, an outage, or an attack. A working audit trail also provides individual accountability: actions can be uniquely traced to the user who performed them, which is mandated by CIS, PCI-DSS (Req-10), NIST AU-controls, and ANSSI R33.
What Pavois checks
Pavois queries systemd for the effective state of auditd.service (systemctl is-enabled / is-active), confirming the daemon is both enabled at boot and currently running. A file-based check (e.g. inspecting /etc/audit/auditd.conf or audit rules) cannot tell whether the daemon is actually alive and consuming the kernel audit backlog, a stopped auditd silently drops events even with a perfect config on disk.
describe service('auditd.service') do
it { should be_enabled }
it { should be_running }
endHow to verify it is applied
Confirm the unit is up:
systemctl is-enabled auditd.service
systemctl is-active auditd.service
Expect enabled and active. You can also confirm the kernel is feeding it with auditctl -s (look for enabled 1 and a non-zero pid).
Inspect & investigate
Audit events are written to /var/log/audit/audit.log. Inspect the daemon itself with systemctl status auditd.service and journalctl -u auditd.service. Note: ausearch can return false "no matches", grep the raw log for a key, e.g. grep 'key="..."' /var/log/audit/audit.log.
Remediation
Pavois's harden plan acts on the service resource named auditd: it runs enable (start at boot) then start (run now). Applied with pavois harden apply. After it runs, the audit daemon persistently records kernel events.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | enable, start |
|---|---|
| name | auditd.service |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Misconfiguration risk: with auditd stopped you lose forensic and compliance evidence and cannot attribute actions to users. Precautions when enabling: auditd writes to /var/log/audit/, ensure the partition has room and review the space_left_action/disk_full_action in auditd.conf, since an aggressive halt/single action on a full disk can take the host down. A very large audit ruleset can add I/O load; size log rotation accordingly. Enabling the service itself does not interrupt running workloads or sessions.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R33 | direct | 2.0 | high |
| CIS | 10.2.1, 6.2.1.2, 6.3.1.4, 6.3.1.2 | direct | per OS, see the benchmark table | high |
| NIST | 3.3.1, AC-2(g), AC-6(9), AU-10, AU-12(c), AU-14(1), AU-2(d), AU-3, CM-6(a), SI-4(23) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 10.2.1 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-653015, UBTU-24-100410 | 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.