Verify User Who Owns Backup shadow File
Ensures /etc/shadow-, the backup copy of /etc/shadow (account password hashes), is group-owned by 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
/etc/shadow- is the backup of /etc/shadow and contains the password hashes of every local account. If its group owner is not the expected privileged group (gid 0), an unprivileged group could read those hashes for offline cracking, or tamper with the backup so a later restore weakens authentication on the live file. This is among the most sensitive files on the system.
What Pavois checks
Pavois reads the effective ownership of /etc/shadow- from the inode (via stat) and asserts gid == 0. Checking the live inode catches drift from manual restores or backup tooling rather than trusting a template. The only_if guard skips the check when the backup is absent.
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 (on Debian/Ubuntu the group may be shadow; this control specifically requires gid 0). If the backup file does not exist the control is skipped.
Inspect & investigate
Ownership changes are not logged by default. Inspect with ls -l /etc/shadow- or stat /etc/shadow-. With an auditd watch (auditctl -w /etc/shadow- -p wa), chown events appear in /var/log/audit/audit.log.
Remediation
No automated harden plan is defined for this rule yet, so it must be applied manually: run chgrp root /etc/shadow- (or chown :root /etc/shadow-) to set gid 0. Consider also tightening its mode to 0000.
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
A wrong group owner on /etc/shadow- can expose password hashes to unprivileged users, enabling offline cracking. Precautions: setting gid 0 is safe, the backup is not used by running services, and does not affect login. On Debian-family systems note the live /etc/shadow is conventionally group shadow; this rule enforces root (gid 0) on the backup, so verify your policy expects that and that no backup tool reverts it.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 7.1.6 | direct | per OS, see the benchmark table | high |
| 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.