← All rules
SOCLE-CLD-FSP-131// File permissionsmediumpersistent config

Verify Permissions on /etc/audit/auditd.conf

Ensures /etc/audit/auditd.conf is not writable by group/other, not readable by other, and carries no executable, setuid, setgid or sticky bits.

Checked against the content of a persistent configuration file, the source of truth that survives reboots.

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 3 standards

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

/etc/audit/auditd.conf drives the auditd daemon: where logs are written, their rotation, the disk-full action and how flushing happens. If it is writable by non-root or readable by other, an attacker can disable logging, redirect the audit trail or simply learn its layout, defeating the forensic record that detects and attributes an incident. Restricting it to root preserves the integrity and confidentiality of the audit configuration.

What Pavois checks

Pavois inspects the live mode of /etc/audit/auditd.conf via the InSpec file resource (equivalent to stat), guarded by only_if so it is skipped when auditd is not installed. It asserts the file is not group/other-writable, not other-readable, and free of setuid/setgid/sticky/executable bits, i.e. an effective mode no looser than 0640 root:root. Checking the real inode permissions, not a packaged default, catches drift introduced by a careless chmod or a bad deployment.

only_if { file('/etc/audit/auditd.conf').exist? }
describe file('/etc/audit/auditd.conf') do
  it { should_not be_executable.by('owner') }
  it { should_not be_setuid }
  it { should_not be_executable.by('group') }
  it { should_not be_writable.by('group') }
  it { should_not be_setgid }
  it { should_not be_executable.by('other') }
  it { should_not be_writable.by('other') }
  it { should_not be_readable.by('other') }
  it { should_not be_sticky }
end

How to verify it is applied

Run stat -c '%a %U %G' /etc/audit/auditd.conf. Expected output is a mode of 640 (or stricter, e.g. 600) owned by root root, for example 640 root root. Any group-write, other-read or special bit (mode beginning with 1/2/4/7) is a failure.

Inspect & investigate

auditd records configuration and daemon events in /var/log/audit/audit.log. Check grep CONFIG_CHANGE /var/log/audit/audit.log for changes, and systemctl status auditd / journalctl -u auditd to confirm the daemon reloaded the config cleanly after any edit.

Remediation

No automated remediation is defined for this rule, so it must be applied manually: run chmod u-x,g-wx,o-rwx /etc/audit/auditd.conf && chown root:root /etc/audit/auditd.conf (target mode 0640 root:root), then reload with systemctl reload auditd or service auditd restart.

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

mode0640
path/etc/audit/auditd.conf
resourcefile
pavois harden plan local

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

Impact & precautions

Tightening these permissions is low-risk: auditd already runs as root and does not need group/other access. Precautions: keep the owner root and avoid chmod 600 only if a non-root monitoring tool must read the config (rare, prefer 640 with a dedicated group). A wrong owner or removing read for root would prevent auditd from starting, verify with auditctl -s and systemctl status auditd afterwards. Leaving it world-readable or group-writable lets unprivileged users discover or tamper with the audit setup.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS6.2.4.5, 6.3.4.5directper OS, see the benchmark tablehigh
NISTAU-12(b)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
DISA STIGUBTU-22-653065, UBTU-24-900040directper 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