Verify User Who Owns Backup gshadow File
Ensures the /etc/gshadow- backup file is owned by root (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
/etc/gshadow- is the backup of /etc/gshadow and contains group password hashes. If it is not owned by root (uid 0), an unauthorized user could read those hashes and attempt offline cracking, or tamper with the backup. Because it holds credential material, protecting this file is critical to system security.
What Pavois checks
Pavois reads the file's effective owning uid with the InSpec file resource and asserts it equals 0 (root), only when the file exists. Reading the live filesystem owner reflects the protection currently enforced, catching chown drift, instead of assuming the default created by group tooling was preserved.
only_if { file('/etc/gshadow-').exist? }
describe file('/etc/gshadow-') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U' /etc/gshadow-. Expected output: root. Alternatively ls -l /etc/gshadow- should show root in the owner column.
Inspect & investigate
Ownership is shown by ls -l /etc/gshadow- and stat /etc/gshadow-. The backup is rewritten when group passwords change (gpasswd, groupmod). If auditd watches /etc/gshadow- (a standard identity-file watch), chown and write events appear in /var/log/audit/audit.log.
Remediation
No automated harden plan is shipped for this rule, so it must be remediated manually: run chown root /etc/gshadow- (commonly paired with chgrp shadow on Debian/Ubuntu or chgrp root on RHEL, and chmod 0000/0600 to match /etc/gshadow).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| owner | root |
|---|---|
| path | /etc/gshadow- |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Non-root ownership exposes group password hashes to reading and offline cracking, or to tampering, a serious credential-compromise risk. Restoring root ownership has no operational impact; only group-management tools touch this file. Precaution: if /etc/gshadow- is absent the check is skipped; re-run after the next group-password change. Avoid loosening permissions further than /etc/gshadow itself.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 7.1.8 | 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.