Verify Group Who Owns /var/log Directory
Ensures the /var/log directory is group-owned by root (GID 0) so only the root group controls the system log tree.
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 is the parent directory for all system logs. Its group ownership governs who can create, rename or remove log files inside it. If a non-root group owns the directory, members could delete or substitute logs to hide activity, or stage files that interfere with logging. Setting the group to root (GID 0) keeps control of the log tree with the most privileged group.
What Pavois checks
Pavois reads the resolved numeric GID of /var/log via the InSpec file resource and asserts it equals 0. It inspects the live inode metadata, so the result reflects the directory's actual ownership rather than an installer default.
only_if { file('/var/log').exist? }
describe file('/var/log') do
its('gid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%g %G' /var/log. The expected output is:
0 root
List it with ls -ld /var/log to confirm the group column shows root.
Inspect & investigate
Changes to the directory are not logged by syslog itself. To trace them, add an auditd watch (auditctl -w /var/log -p wa -k logperms) and grep /var/log/audit/audit.log for key="logperms". General logging health is visible with journalctl --disk-usage and systemctl status rsyslog.
Remediation
This rule has no automated harden plan in Pavois. Apply it manually by setting the directory group to root: chgrp root /var/log (do not use -R, since some subdirectories legitimately use other groups such as adm or utmp).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| path | /var/log |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If a non-root group owns /var/log, its members could remove or replace log files to erase evidence, undermining audit and forensics. Correcting the directory's group is non-disruptive. Precaution: change only the /var/log directory itself, NOT recursively, files like /var/log/auth.log (group adm) and /var/log/lastlog (group utmp) must keep their own groups, so a recursive chgrp would break other compliance rules and possibly logging.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| DISA STIG | UBTU-22-232125, UBTU-24-700100 | direct | per OS STIG release | 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.