Verify Permissions on group File
Ensures /etc/group is not writable by group or other and carries no executable, setuid, setgid or sticky bits (expected mode 0644 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/group defines the groups and their memberships that drive much of the system's access control. It is world-readable by design (programs resolve group names), but it must not be writable by group or other: anyone who can write it could add themselves to sudo, wheel, docker or shadow and escalate to root. Restricting writes to root preserves the integrity of group-based authorization.
What Pavois checks
Pavois reads the real inode permissions of /etc/group with the InSpec file resource (a stat), under only_if. World-read is allowed (the file is meant to be readable), but group-write, other-write, and any execute/setuid/setgid/sticky bit fail the rule, effectively requiring 0644 root:root. Checking the live permissions catches a chmod mistake or a bad backup restore that a packaged-default assumption would not.
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' /etc/group. Expected output is mode 644 owned by root root, i.e. 644 root root. Any group-write, other-write or special bit fails the rule.
Inspect & investigate
Group changes are normally made via groupadd/gpasswd/usermod, which log to /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL). Use getent group to list the effective groups and stat /etc/group to confirm permissions. If auditd watches /etc/group, edits appear in /var/log/audit/audit.log.
Remediation
No automated remediation is defined, so apply it manually: chmod u-x,g-wx,o-wx /etc/group && chown root:root /etc/group (target 0644 root:root). No service restart is needed; new logins immediately see the corrected permissions.
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
Restoring 0644 root:root is very low-risk, this is the standard mode every tool expects. Do not remove world-read: utilities like ls -l and id resolve group names through it, and stripping read can break name resolution and logins. Keep the owner root. There is no lockout risk from removing group/other write. Leaving the file writable by non-root is a direct privilege-escalation path.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | high |
| CIS | 2.2.6, 7.1.3 | 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 |
| 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.