Verify User Who Owns gshadow File
Ensures the /etc/gshadow file is owned by the root user (UID 0).
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
/etc/gshadow stores group password hashes and group administrator lists. If a non-root user owns it, they could read the hashes for offline cracking or set a group password to gain membership of a privileged group via newgrp, a privilege-escalation path. Ownership by root is critical for system security.
What Pavois checks
Pavois stats the live inode of /etc/gshadow and asserts its owner is UID 0. Reading the actual filesystem metadata reflects the effective ownership in force, which the shadow utilities rely on, not an installer default.
only_if { file('/etc/gshadow').exist? }
describe file('/etc/gshadow') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U %u' /etc/gshadow. The expected output is root 0.
Inspect & investigate
Group password changes via gpasswd are logged in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family). To detect direct edits, set an audit watch: auditctl -w /etc/gshadow -p wa -k gshadow, then review /var/log/audit/audit.log (grep for key="gshadow").
Remediation
No automated harden plan is defined for this rule yet, so it must be fixed manually: run chown root /etc/gshadow to restore root ownership.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| owner | root |
|---|---|
| path | /etc/gshadow |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A non-root owner of /etc/gshadow can read or set group password hashes and escalate privileges. Fixing it is essentially risk-free: chown root /etc/gshadow does not change any entry, so authentication keeps working. Combine with strict permissions (chmod 0000 or 0640 root:shadow per distro convention) so the hashes are not readable. The change applies immediately.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | high |
| CIS | 7.1.7 | direct | per OS, see the benchmark table | high |
| NIST | AC-6(1), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.