Audit Configuration Files Permissions are 640 or More Restrictive
Ensures the audit configuration tree /etc/audit is not other-readable, not group/other-writable, and carries no executable or special (setuid/setgid/sticky) bits, i.e. 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 audit configuration under /etc/audit (auditd.conf, audit.rules, rules.d/, plugins.d/) defines which events are recorded and how. If these files are group/other-writable, an attacker could silently disable rules so their actions go unlogged; if they are other-readable they reveal exactly what is, and is not, monitored, helping an intruder evade detection. Restricting to 0640 (or stricter for the directory) keeps audit policy under root's exclusive control and preserves the integrity of the audit trail.
What Pavois checks
Pavois reads the live mode bits of /etc/audit via the InSpec file resource, the permissions the kernel actually enforces, rather than a packaging assumption. This catches a config loosened after install. Note: this control inspects the /etc/audit node; a thorough hardening also applies 0640 recursively to rules.d/*.rules. The only_if guard skips the check when audit is not installed.
only_if { file('/etc/audit').exist? }
describe file('/etc/audit/auditd.conf') do
it { should_not be_executable }
it { should_not be_writable.by('group') }
it { should_not be_readable.by('other') }
it { should_not be_writable.by('other') }
endHow to verify it is applied
Run stat -c '%a %U %G %n' /etc/audit /etc/audit/auditd.conf /etc/audit/rules.d/*.rules. Expected output shows 640 (files) / 750 or 700 (the directory) owned by root root, with no other-read or group-write.
Inspect & investigate
auditd reports its loaded policy with auditctl -l and its status with auditctl -s; events land in /var/log/audit/audit.log. Watch for changes to the config itself by adding an auditd watch on /etc/audit and grepping the log for its key.
Remediation
Pavois applies mode 0750 to the /etc/audit directory (owner root keeps read/write/search, group read/search, no access for others). This is automated, apply it with pavois harden apply. Critical: /etc/audit is a directory, so it MUST keep the owner execute/search bit. Never set a file-style 0640 on it: a directory without x cannot be traversed, and under SELinux enforcing the confined auditd_t domain is then denied the dac_read_search capability, so auditd fails to start with Error opening config file (/etc/audit/auditd.conf): Permission denied. If that happens, recover with chmod 750 /etc/audit /etc/audit/rules.d && restorecon -R /etc/audit.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| mode | 0640 |
| owner | root |
| path | /etc/audit/auditd.conf |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: a writable audit config lets an attacker turn off logging; a readable one maps your detection coverage. Precaution (directory traversal): apply the restriction as a directory mode 0750, not a file mode 0640. Removing the owner search bit (e.g. chmod 0640 or a recursive chmod -R u-x /etc/audit) makes the directory non-traversable; on RHEL/Alma/Fedora under SELinux enforcing this denies auditd_t the dac_read_search capability and bricks auditd at boot. Recovery: chmod 750 /etc/audit /etc/audit/rules.d && restorecon -R /etc/audit, then confirm with systemctl is-active auditd and auditctl -l. Only root and the auditd daemon read these files, so 0750 is safe.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 6.3.4.5 | direct | per OS, see the benchmark table | high |
| NIST | AU-12 b | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.