Verify Group Who Owns /var/log/messages File
Ensures the /var/log/messages system log is group-owned by root (gid 0).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
Why this rule matters
On RHEL-family systems /var/log/messages is the primary catch-all system log, recording kernel, daemon and error events. It must be group-owned by root (gid 0) so that ordinary users cannot read sensitive operational data, error traces, service versions, hostnames and authentication side-channels that aid an attacker's reconnaissance.
What Pavois checks
Pavois reads the effective owning gid of the file with the InSpec file resource and asserts it equals 0 (root), only when the file exists. Checking the actual filesystem metadata captures the state the kernel enforces right now, including drift introduced by log rotation or manual changes, which a static config or package check cannot see.
only_if { file('/var/log/messages').exist? }
describe file('/var/log/messages') do
its('gid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%g %G' /var/log/messages. Expected output: 0 root. Alternatively ls -l /var/log/messages should show root in the group column.
Inspect & investigate
Ownership is shown by ls -l /var/log/messages and stat /var/log/messages. If auditd watches /var/log, chgrp/chown syscalls land in /var/log/audit/audit.log. The file itself is produced by rsyslog, inspect its status with systemctl status rsyslog and its rules in /etc/rsyslog.conf.
Remediation
No automated harden plan is shipped for this rule, so it must be remediated manually: run chgrp root /var/log/messages (and ideally fix any rotated copies, e.g. chgrp root /var/log/messages-*). Ensure your logrotate/rsyslog configuration recreates the file with the correct group.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| path | /var/log/messages |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A non-root owning group exposes the system's main log to unprivileged users, enabling reconnaissance and possible tampering. Restoring root ownership is safe for normal operation since log writers run as root. Precaution: verify no monitoring/SIEM agent reads /var/log/messages under a dedicated non-root group; if it does, grant access via ACL or a dedicated read group rather than weakening ownership.