Verify Permissions on Backup gshadow File
Ensures the backup file /etc/gshadow- 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/gshadow- is the backup of /etc/gshadow and contains group password hashes and the list of group administrators. Any read access by group or other exposes those hashes to offline cracking, and any write access lets an attacker forge group credentials that become live if the backup is restored. This file must be mode 0000 (no permissions, accessed only by root via privileged tools) and owned by root.
What Pavois checks
Pavois reads the live mode bits of /etc/gshadow- via the InSpec file resource. The matchers are unusually strict, even owner read/write is rejected, because the file is meant to be accessed only by root through setuid tools (gpasswd, vigr), which bypass DAC. Inspecting the real inode catches a backup left readable by a sloppy copy. The only_if guard skips the check when no backup exists.
only_if { file('/etc/gshadow-').exist? }
describe file('/etc/gshadow-') 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/gshadow-. Expected output is 0 root root /etc/gshadow- (mode 0000).
Inspect & investigate
The backup is regenerated by group-management tools (gpasswd, groupadd, groupmod, vigr); their activity appears in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family). Track permission/read access via an auditd watch and grep gshadow- /var/log/audit/audit.log.
Remediation
No automated remediation is defined, so apply it manually: chown root:root /etc/gshadow- && chmod 0000 /etc/gshadow-. Root still reads it via privileged tools, so mode 0000 does not break anything.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0640 |
|---|---|
| path | /etc/gshadow- |
| 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 group password hashes can be cracked offline, and a writable backup can inject forged group credentials on restore. Precautions: mode 0000 is the long-standing default for shadow backups and is fully transparent, root and setuid group tools (gpasswd, vigr) access it regardless of DAC bits. No service reads it directly, so there is no lockout risk.
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 |
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.