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

Record Events that Modify the System's Discretionary Access Controls - chmod

Ensures auditd has a live rule tagged perm_mod recording every change to file permissions/ownership (DAC).

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

Changes to file permissions, ownership and ACLs (the discretionary access controls) are how an attacker opens up files they should not reach, or hides the traces of an intrusion. Auditing the chmod/chown/setxattr family of syscalls under the perm_mod key produces an immutable record that lets responders reconstruct who altered access rights and when, surfacing patterns of abuse by both authorized and unauthorized users.

What Pavois checks

Pavois runs auditctl -l and checks that the loaded ruleset contains a rule keyed perm_mod. This is the effective, kernel-loaded ruleset, not the contents of /etc/audit/rules.d/. A rule present in a file but never loaded (syntax error, missing augenrules --load, pending reboot) would pass a file scan yet fail here, which is exactly the gap Pavois is built to catch.

describe command('auditctl -l') do
  its('stdout') { should match(/(-k +|key=)perm_mod\b/) }
end
describe command("grep -rhwsE 'perm_mod' /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 perm_mod. Expected: one or more lines ending in -k perm_mod (or key=perm_mod), covering chmod, chown, setxattr, etc. No output means the rule is not loaded.

Inspect & investigate

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

Remediation

pavois harden apply uses the audit_ruleset resource: it writes the DAC-modification audit rules (keyed perm_mod) into auditd's rules directory and reloads the ruleset. This rule is flagged reboot_required, so a reboot guarantees the new rules are active from boot and any immutable (-e 2) configuration 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, permission and ownership tampering happens invisibly, crippling incident investigation and breaking PCI/STIG audit-trail requirements. Applying it adds audit rules and may require a reboot; on busy systems a high volume of chmod/chown events can grow /var/log/audit/ quickly, so size max_log_file/space_left appropriately before enabling.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R73direct2.0high
CIS10.3.4, 6.2.3.9, 6.3.3.18, 6.3.3.9directper 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.3.4supporting4.0.1medium
DISA STIGUBTU-22-654155, UBTU-22-654160, UBTU-22-654180, UBTU-24-900150, UBTU-24-900140, UBTU-24-900130directper 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