Verify Permissions on Backup shadow File
Ensures the backup file /etc/shadow- is unreadable, unwritable and non-executable by owner, group and other, with no special bits, i.e. mode 0000.
Checked against what is installed or registered, packages present/absent, account databases.
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. Any read access by group or other exposes those hashes to offline brute-force/dictionary cracking, and any write access lets an attacker clear or replace a password (e.g. blank out root's) that becomes live if the backup is restored. This file must be mode 0000 (accessed only by root through privileged tools) and owned by root.
What Pavois checks
Pavois reads the live mode bits of /etc/shadow- via the InSpec file resource. The matchers are deliberately strict, even owner read/write is rejected, because the file is meant to be reached only by root through setuid tools (passwd, vipw -s), which bypass DAC. Inspecting the real inode catches a backup left readable by a careless copy or restore. The only_if guard skips the check when no backup exists.
only_if { file('/etc/shadow-').exist? }
describe file('/etc/shadow-') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_readable.by('other') }
it { should_not be_sticky }
endHow to verify it is applied
Run stat -c '%a %U %G %n' /etc/shadow-. Expected output is 0 root root /etc/shadow- (mode 0000).
Inspect & investigate
The backup is regenerated by password-management tools (passwd, chpasswd, usermod, vipw -s); their activity appears in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family). Track permission/read access with an auditd watch and grep shadow- /var/log/audit/audit.log.
Remediation
No automated remediation is defined, so apply it manually: chown root:root /etc/shadow- && chmod 0000 /etc/shadow-. Root still reads it via privileged setuid tools, so mode 0000 breaks nothing.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0640 |
|---|---|
| path | /etc/shadow- |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: exposed password hashes can be cracked offline, and a writable backup can wipe or replace a password (including root's) on restore, a full account-takeover path. Precautions: mode 0000 is the long-standing default for shadow and is transparent, root and setuid auth tools (passwd, su, login) read it regardless of DAC bits. No service reads it directly, so there is no lockout risk.
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.