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

Record Attempts to Alter Process and Session Initiation Information

Ensures auditd has a live rule (keyed session) recording changes to utmp/wtmp/btmp session records.

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 22.04CIS 3.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 files that track login sessions and process initiation, /var/run/utmp, /var/log/wtmp and /var/log/btmp, are prime targets for an attacker who wants to erase evidence of a login. Auditing writes to them (under the session key) records any manual tampering, preserving the session history needed to reconstruct who was on the system and to spot attempts to remove intrusion traces.

What Pavois checks

Pavois runs auditctl -l and checks the loaded ruleset for a rule keyed session. It reads the effective kernel ruleset rather than the rule files, so a watch present in /etc/audit/rules.d/ but not loaded (parse error, missing reload, pending reboot) correctly fails here where a file scanner would be fooled.

describe command('auditctl -l') do
  its('stdout') { should match(/(-k +|key=)session\b/) }
end
describe command("grep -rhwsE 'session' /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 session. Expected: watch rules on /var/run/utmp, /var/log/wtmp and /var/log/btmp ending in -k session (or key=session). No output means the rule is not active.

Inspect & investigate

  • Confirm the loaded rule: auditctl -l | grep session.
  • See recorded events: grep 'key="session"' /var/log/audit/audit.log (prefer raw grep; ausearch is unreliable).
  • Service state: systemctl status auditd.

Remediation

pavois harden apply uses the audit_ruleset resource to write the session-tracking watches (keyed session) on utmp/wtmp/btmp into auditd's rules directory and reload the ruleset. The rule is reboot_required, so a reboot guarantees the rules load from boot and any immutable mode takes effect.

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

Without this rule, an attacker can edit session records to hide their presence with no audit trail, defeating forensic timelines and failing PCI/STIG requirements. Applying it adds audit watches and may require a reboot; impact is low, though every login updates these files so expect a steady (small) volume of session events.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R73direct2.0high
CIS6.2.3.11, 6.3.3.20, 6.3.3.11directper OS, see the benchmark tablehigh
NIST3.1.7, AU-12(c), AU-2(d), CM-6(a)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS10.2.1.3supporting4.0.1medium
DISA STIGUBTU-22-654195, UBTU-22-654205, UBTU-22-654200, UBTU-24-900610, UBTU-24-900600, UBTU-24-900590directper 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