← All rules
SOCLE-RUN-AUD-019// Audit (auditd)mediumeffective runtime

Ensure auditd Collects System Administrator Actions

Enforces an auditd rule (key actions) that records system-administrator actions, notably edits to the sudoers configuration.

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.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 5 standards

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 actions taken by system administrators, chiefly edits to the sudoers policy under /etc/sudoers and /etc/sudoers.d/, must be audited to keep a record of what was changed on the system and by whom, for accountability. Because changing the escalation policy is a common attacker technique for establishing persistence, recording these edits provides an early-warning and forensic trail.

What Pavois checks

Pavois runs auditctl -l and checks a rule with the key actions is loaded. Reading the live kernel ruleset beats parsing /etc/audit/rules.d/*.rules: a rule on disk that was never loaded (no augenrules --load, syntax error, reload failure) would make a file scanner falsely pass. auditctl -l reflects what the kernel audits now.

describe command('auditctl -l') do
  its('stdout') { should match(/(-k +|key=)actions\b/) }
end
describe command("grep -rhwsE 'actions' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
  its('stdout') { should match(/\S/) }
end

How to verify it is applied

Run auditctl -l | grep -E '(-k |key=)actions' (as root). Expected output is the watches on the sudoers files, for example:

  • -w /etc/sudoers -p wa -k actions
  • -w /etc/sudoers.d -p wa -k actions

No output means the rules are not loaded.

Inspect & investigate

Events go to /var/log/audit/audit.log. After an administrator edits sudoers, find the record with grep 'key="actions"' /var/log/audit/audit.log (grep the raw log; ausearch can falsely report no matches). The record shows the auid, the file changed and the timestamp.

Remediation

pavois harden apply uses the audit_ruleset resource to add the missing actions watches to a Pavois-managed drop-in in /etc/audit/rules.d/ and load them. Because the audit subsystem is locked once running, the change is fully effective only after a reboot (reboot_required: true).

Pavois applies this with its own harden engine, the plan below, not a shell script:

reboot_requiredtrue
resourceaudit_ruleset
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

This is a passive file watch, it never blocks edits to sudoers, so visudo and configuration management keep working; it only adds records to /var/log/audit/audit.log. Precautions:

  • Audit volume is tiny since sudoers rarely changes, no meaningful performance concern.
  • If the ruleset is immutable (-e 2), the rule can only be added after a reboot.
  • Confirm the rule parsed with augenrules --load and re-check auditctl -l.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R73direct2.0high
CIS10.2.1.5, 6.2.3.1, 6.3.3.1directper OS, see the benchmark tablehigh
NIST3.1.7, AC-2(7)(b), AC-6(9), AU-12(c), AU-2(d), CM-6(a)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS10.2.1.5supporting4.0.1medium
DISA STIGUBTU-24-900510, UBTU-24-900520directper OS STIG releasehigh

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.

Sources & references