Verify Group Who Owns gshadow File
Ensures /etc/gshadow is group-owned by GID 0 (root).
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 holds the hashed passwords for groups. If it is group-owned by anything other than GID 0 (or the dedicated shadow group on Debian/Ubuntu), members of that group could read the hashes and attempt to crack group passwords offline, escalating their access. Restricting group ownership keeps these secrets under root/shadow control.
What Pavois checks
Pavois asks the file resource for the resolved numeric gid of /etc/gshadow and requires it to be 0. The check is skipped if the file does not exist. Querying the file's effective group ownership directly (the kernel-resolved gid) is exact and avoids guessing from a name that could differ across distributions.
only_if { file('/etc/gshadow').exist? }
describe file('/etc/gshadow') do
its('gid') { should eq 42 }
endHow to verify it is applied
Run stat -c '%G %g' /etc/gshadow. Expected: group root and gid 0 (on Debian/Ubuntu the shadow group, gid as defined locally, is also acceptable per distro policy). ls -l /etc/gshadow shows the group column too.
Inspect & investigate
- Inspect ownership:
stat -c '%U %G %a' /etc/gshadoworls -l /etc/gshadow. - Integrity check of the shadow group database:
grpck -r. - If auditd watches
/etc/gshadow, changes appear in/var/log/audit/audit.log.
Remediation
No automated remediation is shipped for this rule. Fix it manually by setting the correct group ownership, e.g. chgrp 0 /etc/gshadow (or chgrp shadow /etc/gshadow where the distro uses the shadow group), then re-run the scan.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | shadow |
|---|---|
| path | /etc/gshadow |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Wrong group ownership of /etc/gshadow exposes group password hashes to a non-root group, enabling offline cracking and privilege escalation. The chgrp fix is trivial and low-risk; just apply the gid expected by your distribution (0 on RHEL family, often shadow on Debian/Ubuntu) so you do not break the local password tooling.
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.