Verify Group Who Owns shadow File
Ensures the /etc/shadow password-hash file is owned by group root (gid 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
The /etc/shadow file stores password hashes for every local account. If its owning group is not root (gid 0), an unprivileged group could be granted read access, exposing hashes to offline cracking and ultimately to account takeover. Restricting group ownership to root is a prerequisite for the strict permissions (typically 0640 root:shadow or 0000) that keep the hashes secret.
What Pavois checks
Pavois resolves the file's actual group id with InSpec's file('/etc/shadow') resource and asserts gid == 0. It reads the effective ownership recorded by the filesystem (the real stat value applied right now), not a packaging manifest or a hardening script that may have drifted, so a manual chgrp or a misbehaving package post-install that changed the group is caught immediately.
only_if { file('/etc/shadow').exist? }
describe file('/etc/shadow') do
its('gid') { should eq 42 }
endHow to verify it is applied
Run stat -c '%G %g' /etc/shadow. Expected output: root 0 (the group name may be shadow on some Debian/Ubuntu installs, in that case confirm with getent group shadow, but this rule mandates gid 0).
Inspect & investigate
Ownership changes are not logged by default. With the auditd watch enabled (auditctl -w /etc/shadow -p wa -k identity), every write or attribute change appears in /var/log/audit/audit.log; filter with grep 'key="identity"' /var/log/audit/audit.log.
Remediation
No automated remediation is wired for this rule, so it must be applied manually: chgrp 0 /etc/shadow (or chgrp shadow /etc/shadow on systems using the shadow group, then confirm gid 0 is intended). Re-run pavois harden verify afterwards.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | shadow |
|---|---|
| path | /etc/shadow |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If the group is too permissive, password hashes can leak to non-root accounts and be cracked offline. Setting the group back to root has essentially no operational risk, passwd, login, PAM and sudo access /etc/shadow as root. Precautions: keep the matching strict mode (0640/0000) and, on Debian/Ubuntu, do not break the shadow group convention used by some tools; verify with getent group shadow before changing.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | high |
| CIS | 2.2.6, 7.1.5 | 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 |
| PCI DSS | 2.2.6 | supporting | 4.0.1 | 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.