System Audit Logs Must Have Mode 0640 or Less Permissive
Ensures the /var/log/audit directory is not group-writable and not readable/writable/executable by other (mode 0640 or stricter).
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
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 /var/log/audit tree holds the auditd trail, the authoritative record of security-relevant events. If non-privileged users can write to it, audit trails can be altered or destroyed, letting an attacker erase evidence of intrusion. If they can read it, sensitive data captured by audit rules (commands, paths, arguments) leaks. Audit logs must be confined to root (and the audit group) with mode 0640 or stricter to protect the integrity and confidentiality of the trail.
What Pavois checks
Pavois reads the effective inode mode of /var/log/audit and asserts no group write and no read/write/execute for other. Reading the live mode (not a vendor manifest) is essential here: auditd, log rotation and manual restores can all reset these permissions, and a tampered audit directory is exactly what an attacker would try to hide.
only_if { file('/var/log/audit').exist? }
describe file('/var/log/audit') do
it { should_not be_writable.by('group') }
it { should_not be_readable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_executable.by('other') }
endHow to verify it is applied
Run stat -c '%U %G %a' /var/log/audit (expect owner root, mode 700 or 750) and stat -c '%a' /var/log/audit/audit.log (expect 600 or 640). No write bit for group, and nothing for other.
Inspect & investigate
The audited events themselves live in /var/log/audit/audit.log; grep it directly (e.g. grep 'key="..."' /var/log/audit/audit.log) rather than relying on ausearch, which can falsely report no matches. auditd's own status is shown by systemctl status auditd and auditctl -s.
Remediation
No automated remediation ships for this rule. Tighten manually: chown root:root /var/log/audit && chmod 700 /var/log/audit (or 750 if an audit group needs read), and chmod 600 /var/log/audit/*.log. The log_group and permissions can also be enforced in /etc/audit/auditd.conf.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0750 |
|---|---|
| path | /var/log/audit |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Loose audit-log permissions let attackers tamper with or read the forensic trail, defeating accountability. Restricting to root is safe; auditd runs as root and is unaffected. Precaution: if a log-shipping or SIEM agent reads /var/log/audit as a non-root user, add it to the audit group and use mode 0640 rather than 0600, or grant access via ACL/log_group, otherwise the collector will silently stop ingesting audit events.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 10.3.1, 6.2.4.1, 6.3.4.2, 6.3.4.1 | direct | per OS, see the benchmark table | high |
| NIST | 3.3.1, AC-6(1), AU-9(4), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 10.3.1, 10.3.2 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-653060, UBTU-24-901380 | 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.