Verify Permissions on Backup group File
Ensures the backup file /etc/group- is not group/other-writable and carries no executable or special (setuid/setgid/sticky) bits, i.e. mode 0644 or stricter.
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/group- is the backup copy of /etc/group and lists every group and its membership, including administrative groups such as sudo, wheel and adm. If it is group/other-writable, an attacker could add their account to a privileged group in the backup; should /etc/group ever be restored from it, that membership becomes live, a stealthy path to privilege escalation. Mode 0644 or stricter, owned by root, keeps the backup tamper-resistant.
What Pavois checks
Pavois reads the live mode bits of /etc/group- via the InSpec file resource, the permissions the kernel enforces, rather than the default the package would set. Backup files are easy to overlook and are sometimes left world-writable by ad-hoc copies; inspecting the real inode catches that. The only_if guard skips the check when no backup exists yet.
only_if { file('/etc/group-').exist? }
describe file('/etc/group-') 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_sticky }
endHow to verify it is applied
Run stat -c '%a %U %G %n' /etc/group-. Expected output is 644 root root /etc/group- (or stricter, e.g. 600).
Inspect & investigate
These backups are regenerated by user/group management tools (useradd, groupadd, vipw, vigr); their actions show up in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family). Permission changes can be tracked with an auditd watch and grep group- /var/log/audit/audit.log.
Remediation
No automated remediation is defined, so apply it manually: chown root:root /etc/group- && chmod u-x,g-wx,o-wx,a-s /etc/group- (a plain chmod 644 /etc/group- reaches the target mode).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0644 |
|---|---|
| path | /etc/group- |
| 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: a tampered group backup can seed privileged group membership on restore. Precautions: tightening these permissions is safe, /etc/group- is only read by administrative tooling running as root, and the world-readable default (0644) is acceptable since group names are not secret. There is no service dependency and no lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 7.1.4 | 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.