Verify User Who Owns /var/log/auth.log File
Ensures the authentication log /var/log/auth.log is owned by the syslog user so only the logging daemon can write it.
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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 and PAM authentication events, exactly the data an attacker wants to read (to harvest usernames and timing) or write (to forge or erase traces of an intrusion). If the file is not owned by the dedicated syslog account, an unprivileged or compromised process could tamper with the authentication trail, destroying the evidence needed for forensic investigation and accountability.
What Pavois checks
Pavois checks that the owner of /var/log/auth.log is syslog, but only when the file exists (only_if). It reads the live owner reported by the filesystem (stat) on the target, not a packaging default or a logrotate template, so even if a misbehaving cron job, log-shipping agent or rotation hook chown-ed the file, the control reflects the effective on-disk state at scan time.
only_if { file('/var/log/auth.log').exist? }
describe command("stat -c %U /var/log/auth.log 2>/dev/null") do
its('stdout.strip') { should be_in ['root', 'syslog'] }
endHow to verify it is applied
Confirm the owner with:
stat -c '%U' /var/log/auth.log
Expected output is syslog.
Inspect & investigate
This file is the authentication log. Inspect its content and ownership directly:
ls -l /var/log/auth.log
tail -n 50 /var/log/auth.log
The rsyslog daemon that owns it can be checked with systemctl status rsyslog. Ownership changes can be tracked, if auditd file-watches are configured, with grep 'auth.log' /var/log/audit/audit.log.
Remediation
Pavois's harden plan uses a file resource to set the owner of /var/log/auth.log to syslog. Run pavois harden apply to enforce it, the Chef engine issues the equivalent of chown syslog /var/log/auth.log and leaves the file otherwise untouched (content and group preserved).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | chown root /var/log/auth.log 2>/dev/null; true |
|---|---|
| name | log-owner-var-log-auth.log |
| not_if | stat -c %U /var/log/auth.log 2>/dev/null | grep -qxE 'root|syslog' |
| path | /var/log/auth.log |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Consequences if misconfigured: wrong ownership lets a non-logging user read sensitive authentication data or alter/erase the audit trail, undermining accountability and incident response.
Precautions before applying: changing the owner to syslog is safe and non-disruptive, rsyslog already runs as syslog on Debian/Ubuntu, so it keeps writing normally. Ensure the syslog user exists (it does on a standard rsyslog install) before applying; if you ship logs with an agent running as another user, confirm that agent reads via group or root rather than relying on file ownership, so the chown does not break collection.
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.