← All rules
SOCLE-CLD-FSP-087// File ownershipmediumfilesystem state

Verify User Who Owns shadow File

Ensures the password-hash database /etc/shadow is owned by root (UID 0).

Checked against a path’s metadata, mode, owner, group, SUID/SGID.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 4 standards

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 lists local accounts and stores their password hashes and aging metadata. If a non-root account owns it, that user could read the hashes (enabling offline cracking) or edit them to set/clear passwords, a direct credential-compromise and privilege-escalation path. Setting root (UID 0) as the owner keeps this highly sensitive file under exclusive privileged control.

What Pavois checks

Pavois inspects the live filesystem with the InSpec file('/etc/shadow') resource and asserts uid == 0, guarded by only_if. Reading the real inode owner (not a provisioning template) reveals the effective state on disk, catching any post-deployment chown that would expose password hashes.

only_if { file('/etc/shadow').exist? }
describe file('/etc/shadow') do
  its('uid') { should eq 0 }
end

How to verify it is applied

Run stat -c '%U %u %n' /etc/shadow. Expected output: root 0 /etc/shadow. The numeric 0 confirms root ownership.

Inspect & investigate

Distributions usually ship an audit rule on this file (key identity); inspect /var/log/audit/audit.log with grep 'key="identity"'. If absent, add auditctl -w /etc/shadow -p wa -k identity. Password changes are also logged by PAM in /var/log/auth.log / journalctl (passwd, pam_unix).

Remediation

No automated remediation is shipped for this rule. Apply it manually with chown root /etc/shadow (run as root or via sudo); the file should be group shadow (Debian/Ubuntu) or root (RHEL) and mode 0640/0000 per distro, never widen its permissions.

Pavois applies this with its own harden engine, the plan below, not a shell script:

ownerroot
path/etc/shadow
resourcefile
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

A non-root owner of /etc/shadow directly exposes every password hash and enables account takeover. Risk of applying: very low, root ownership is the system default and does not break authentication. Precaution: correct only the owner; do NOT relax the group/mode (Debian uses group shadow with 0640, RHEL uses 0000), widening them is itself a finding.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R50direct2.0high
CIS2.2.6, 7.1.5directper OS, see the benchmark tablehigh
NISTAC-6(1), CM-6(a)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS2.2.6supporting4.0.1medium

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.

Sources & references