← All rules
SOCLE-CLD-FSP-042// File ownershipmediumfilesystem state

Verify Group Who Owns /var/log/auth.log File

Ensures /var/log/auth.log is group-owned by adm so authentication records stay confidential and tamper-resistant.

Checked against a path’s metadata, mode, owner, group, SUID/SGID.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

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 authentication events, the primary forensic trail after an incident. If a non-privileged group owns it, an attacker could read it to harvest usernames and timing, or tamper with it to erase their tracks. Restricting the file to the adm group preserves the integrity and confidentiality of authentication records.

What Pavois checks

Pavois reads the resolved group ownership of /var/log/auth.log via the InSpec file resource and asserts the group is adm. It inspects the live inode metadata at audit time, so it reflects the file's actual ownership, even after log rotation may have recreated it.

only_if { file('/var/log/auth.log').exist? }
describe file('/var/log/auth.log') do
  its('group') { should eq 'adm' }
end

How to verify it is applied

Run stat -c '%G' /var/log/auth.log. The expected output is:

  • adm

List it with ls -l /var/log/auth.log and check rotated copies with ls -l /var/log/auth.log*.

Inspect & investigate

This file is itself the authentication log: inspect it with tail -f /var/log/auth.log or, for the systemd journal equivalent, journalctl -u ssh and journalctl _COMM=sudo. To trace permission changes on it, add an auditd watch (auditctl -w /var/log/auth.log -p wa -k logperms) and grep /var/log/audit/audit.log for key="logperms".

Remediation

Pavois's harden plan applies the file resource to set the group of /var/log/auth.log to adm. It is applied with pavois harden apply and leaves the owner and permission bits untouched.

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

groupadm
path/var/log/auth.log
resourcefile
pavois harden plan local

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

Impact & precautions

Wrong group ownership exposes authentication history to unprivileged users and can let an attacker cover their tracks. The fix only changes group ownership, with no service impact. Precaution: ensure rsyslog/logrotate recreate the file with group adm (check /etc/logrotate.d/rsyslog and the create directive) so the setting persists across rotations; otherwise the next rotation could revert it.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS6.1.4.1, 6.2.2.1directper OS, see the benchmark tablehigh

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