Verify the group owning the /var/log directory
Ensures every file under /var/log is group-owned by root, adm or syslog.
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
The /var/log tree holds system, authentication and audit logs that must only be reachable by authorized administrators. A log file group-owned by something other than root, adm or syslog can be read by members of that group, exposing error messages, credentials or session data, or modified to erase evidence of an attack. Restricting the group owner keeps confidentiality and integrity of the audit trail.
What Pavois checks
Pavois runs find /var/log -type f ! -group root ! -group adm ! -group syslog and expects empty output. Auditing the live filesystem catches logs created at runtime by daemons, rotated files and operator-dropped files that a static file-list or package check would miss.
describe command('timeout 90 find /var/log -type f ! -group root ! -group adm ! -group syslog ! -group utmp ! -group systemd-journal 2>/dev/null') do
its('exit_status') { should_not cmp 124 } # timeout killed the scan: no evidence, not a pass
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run the scan manually:
find /var/log -type f ! -group root ! -group adm ! -group syslog
Expected output: nothing (empty). Inspect any printed file with ls -l <file>.
Inspect & investigate
List offenders with their group via find /var/log -type f ! -group root ! -group adm ! -group syslog -printf '%g %p\n'. After fixing, confirm with ls -lg /var/log/. Ownership changes are themselves recorded only if an auditd watch on chgrp is configured.
Remediation
No automated harden plan is defined for this rule, so it must be applied manually. Re-group the offending files with chgrp root <file> (or adm/syslog where appropriate). Note that on Debian/Ubuntu the related findloop-file-groupownerships-var-log rule does ship an automated fix, this RHEL/Ubuntu-scoped variant intentionally leaves it to the administrator.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | find /var/log -type f ! -user root ! -user syslog -exec chown root {} + 2>/dev/null; find /var/log -type f ! -group root ! -group adm ! -group syslog ! -group utmp ! -group systemd-journal -exec chgrp root {} + 2>/dev/null; true |
|---|---|
| name | fix-varlog-ownership |
| not_if | test -z "$(find /var/log -type f \( ! -user root ! -user syslog -o ! -group root ! -group adm ! -group syslog ! -group utmp ! -group systemd-journal \) 2>/dev/null | head -1)" |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if left as-is: logs readable or writable by an unprivileged group can leak secrets or be tampered with to hide an intrusion. Before fixing: some services (e.g. a database or web server writing into /var/log/<service>/) deliberately own their logs with a dedicated group; forcing root:adm can break log rotation or stop the daemon writing. Review the listed files and exclude legitimate service-owned subtrees instead of mass-rewriting.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R71 | direct | 2.0 | high |
| CIS | 6.1.4.1, 6.2.4.1, 6.2.6.1, 6.2.3.1, 6.2.2.1 | direct | per OS, see the benchmark table | high |
| PCI DSS | 10.3.2 | supporting | 4.0.1 | medium |
| 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.