← All rules
SOCLE-CLD-FSP-020// File ownershipmediumfilesystem state

Verify Group Who Owns group File

Ensures the /etc/group file is group-owned by root (gid 0).

Checked against a path’s metadata, mode, owner, group, SUID/SGID.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 4 standards

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

The /etc/group file defines every group on the system and its membership, and group membership grants privileges (e.g. sudo, wheel, docker, disk). If the file is group-owned by a non-privileged group, a member of that group could, combined with loose permissions, add itself to a privileged group and escalate to root or equivalent. Restricting group ownership to root (gid 0) ensures only highly-privileged accounts can influence group membership.

What Pavois checks

Pavois reads the effective group owner of /etc/group on the live system via the InSpec file resource and asserts gid == 0. It inspects the actual inode metadata as the kernel sees it, not a packaging default, so a file whose ownership drifted after install (or after a restore from backup) is caught.

only_if { file('/etc/group').exist? }
describe file('/etc/group') do
  its('gid') { should eq 0 }
end

How to verify it is applied

Run stat -c '%G %g' /etc/group. Expected output: root 0. Any other group name or non-zero gid means the rule is not applied.

Inspect & investigate

Ownership changes are not logged by default. Watch the file with auditd: auditctl -w /etc/group -p wa -k identity, then inspect grep 'key="identity"' /var/log/audit/audit.log. Group membership edits made through tooling are also visible in /var/log/auth.log (Debian/Ubuntu) or journalctl entries from groupadd/gpasswd/usermod.

Remediation

No automated remediation is defined for this rule, so it must be applied manually. Restore the correct group ownership with chgrp root /etc/group.

Pavois applies this with its own harden engine, the plan below, not a shell script:

grouproot
path/etc/group
resourcefile
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

A non-root group owner on /etc/group weakens the trust boundary around group membership, a known privilege-escalation lever. Restoring root ownership is low-risk: chgrp root changes only group ownership, not content or permissions, and authentication keeps working. Precaution: never blank, truncate, or change permissions on /etc/group while fixing ownership, a corrupt group file can break sudo, login, and service startup; keep /etc/group at mode 0644 owned root:root.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R50direct2.0high
CIS2.2.6, 7.1.3directper OS, see the benchmark tablehigh
NISTAC-6(1), CM-6(a)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS2.2.6supporting4.0.1medium

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.

Sources & references