Verify Group Who Owns Backup shadow File
Ensures the backup shadow file /etc/shadow- 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
The /etc/shadow- file is the backup of /etc/shadow and holds password hashes for every local account. If it is not owned by root, an unprivileged user could read these hashes and run offline password cracking, or tamper with them to weaken authentication. Because backup files are easy to forget, weak ownership here is a common path to credential compromise.
What Pavois checks
Pavois reads the effective owner of /etc/shadow- via the InSpec file resource and asserts uid == 0, only when the file exists (only_if). Reading the live inode ownership shows the true state on disk, including drift introduced after a manual edit or a misbehaving backup script, rather than an assumed default.
only_if { file('/etc/shadow-').exist? }
describe file('/etc/shadow-') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U %u' /etc/shadow-. Expected output: root 0. Alternatively ls -l /etc/shadow- should show root in the owner column.
Inspect & investigate
Ownership has no service log. Confirm the state with stat -c '%U %u' /etc/shadow-. To trace changes, an auditd watch such as auditctl -w /etc/shadow- -p wa -k shadow-backup records writes/attribute changes in /var/log/audit/audit.log.
Remediation
No automated harden plan is defined for this rule, so it must be applied manually: run chown root /etc/shadow- as root to set the owner to root.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| owner | root |
|---|---|
| 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 misconfigured, password hashes in the backup are exposed to offline cracking or tampering by non-root users, a direct credential-theft risk.
Precautions before applying: chown root /etc/shadow- is safe and reversible. Confirm you target the backup (trailing -), not /etc/shadow. No service restart and no lockout risk; ownership of the active /etc/shadow is unaffected.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 7.1.6 | direct | per OS, see the benchmark table | high |
| NIST | AC-6 (1) | 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.