Verify Permissions on shadow File
Ensures /etc/shadow carries no read/write/execute access for owner, group or other and no setuid/setgid/sticky bits, keeping password hashes out of reach of every account.
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 stores the password hashes of every local account along with aging metadata. It is one of the most sensitive files on the system: any read access by group or other exposes the hashes to offline cracking, and write access allows blanking a password or injecting a known hash to take over an account. This rule is strict, it also forbids the owner read/write/execute bits, because the file is meant to be mediated through shadow-group tooling, not opened directly. No setuid/setgid/sticky/executable bit belongs here. Effective protection of this file is critical for system security.
What Pavois checks
Pavois reads the live mode bits of /etc/shadow on the target, every owner/group/other read, write and execute bit plus setuid/setgid/sticky, directly from the inode the kernel enforces, not from a documented baseline. There is no include or drop-in that could hide an over-permissive mode. The only_if guard skips the control if the file is absent.
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' /etc/shadow. Expected: mode ---------- (0000) on Debian/Ubuntu owned by root shadow, or 0000/0640 root root on RHEL, in all cases no read/write bit for group or other. Quick check: find /etc/shadow -perm /7077 must return nothing.
Inspect & investigate
Permission changes are not logged by default. Watch this critical file with auditd: auditctl -w /etc/shadow -p wa -k identity, then review with grep 'key="identity"' /var/log/audit/audit.log. Password changes and authentication using these hashes appear in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL). Current mode and ownership: stat /etc/shadow.
Remediation
No automated harden plan ships for this rule yet, so it must be applied manually. On Debian/Ubuntu: chown root:shadow /etc/shadow && chmod 0640 /etc/shadow (the historical mode) or 0000; on RHEL: chown root:root /etc/shadow && chmod 0000 /etc/shadow. The exact secure mode depends on the distribution, match what the OS vendor ships. This removes all group/other read and any setuid/setgid/sticky bits.
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 left mis-set: readable /etc/shadow hands every account the password hashes for offline cracking, the single most damaging file-permission failure; writable /etc/shadow allows direct account takeover. Applying the fix is safe because privileged tools (passwd, login, PAM) access the file as root or via the shadow group, not through normal read bits. Precaution: do not make it world-readable or remove the shadow group ownership on Debian/Ubuntu, passwd relies on it to update hashes for unprivileged users.
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.