Verify Permissions on /var/log/auth.log File
Ensures /var/log/auth.log is not writable by group/other, not readable by other, and carries no execute/setuid/setgid/sticky bits.
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
/var/log/auth.log records login attempts, sudo use, SSH sessions and PAM authentication events. If other can read it, an attacker enumerates valid usernames, login sources and authentication patterns useful for targeted attacks; sometimes it even captures mistyped passwords entered at a username prompt. If non-root users can write to it, they can forge or erase authentication evidence. It must be writable only by root and not readable by other.
What Pavois checks
Pavois reads the effective inode mode of /var/log/auth.log and asserts no group/other write, no other read, and no special bits. Reading the live file beats a manifest: logrotate recreates this log on every rotation, so its mode is determined at runtime and can drift from any documented default.
only_if { file('/var/log/auth.log').exist? }
describe file('/var/log/auth.log') 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 }
endHow to verify it is applied
Run stat -c '%U %G %a' /var/log/auth.log. Expected: owner root, group adm, mode 640 (or stricter 600), no write for group/other and no read for other.
Inspect & investigate
This file is the authentication log: tail it with tail -f /var/log/auth.log, or use journalctl -u ssh / journalctl _COMM=sudo for the same events via the journal. After log rotation, re-check the mode on the freshly created file.
Remediation
No automated remediation ships for this rule. Tighten manually: chown root:adm /var/log/auth.log && chmod 640 /var/log/auth.log. To make it persist across rotations, ensure /etc/logrotate.d/rsyslog uses a create 640 root adm directive.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0640 |
|---|---|
| path | /var/log/auth.log |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
World-readable auth logs leak usernames and login patterns; writable ones let attackers cover their tracks. Setting 640 root:adm is the Debian/Ubuntu default and safe. Precaution: members of the adm group (and tools relying on it) keep read access, do not switch to 600 if a non-root log viewer or SIEM agent reads via the adm group, or it will lose visibility. Verify the logrotate create mode so the hardening survives the next rotation.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 6.1.4.1, 6.2.2.1 | direct | per OS, see the benchmark table | 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.