Verify Permissions on gshadow File
Ensures /etc/gshadow is unreadable and unwritable by everyone (owner included) and free of any execute/setuid/setgid/sticky bit (expected mode 0000 root:root).
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 stores group password hashes and group administrator lists. If any account other than root can read it, those hashes become a target for offline cracking; if it is writable, an attacker can grant themselves group administration or membership. It should be 0000 root:root (no read or write for anyone, even the owner), the kernel still lets root access it. This keeps group secrets confidential and the file tamper-proof.
What Pavois checks
Pavois reads the real inode permissions of /etc/gshadow with the InSpec file resource (a stat), under only_if. Unlike most files, it forbids even owner read/write: the secure mode is 0000 root:root, root accessing it through superuser privilege. Any read or write bit for owner, group or other, or a special bit, fails. Verifying the live permissions catches drift a packaged-default check would miss.
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' /etc/gshadow. Expected output is mode 0 owned by root root, i.e. 0 root root (some distros use 000). Any read or write bit fails the rule.
Inspect & investigate
Group password operations go through gpasswd, which logs to /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL). Confirm permissions with stat /etc/gshadow. If auditd watches /etc/gshadow, access and edits appear in /var/log/audit/audit.log.
Remediation
No automated remediation is defined, so apply it manually: chmod 0000 /etc/gshadow && chown root:root /etc/gshadow. No service restart is needed; gpasswd and friends still operate as root regardless of the 0000 mode.
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
Setting 0000 root:root is safe: the tools that read /etc/gshadow (gpasswd, newgrp) are setuid-root or run as root and bypass the empty mode. There is no lockout risk. Precaution: keep the owner root, a wrong owner combined with 0000 would make even legitimate tools fail. Leaving the file readable exposes group password hashes to offline cracking.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | high |
| CIS | 7.1.7 | 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 |
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.