Ensure all files are owned by a group
Ensures no file on a local filesystem has an unassigned group owner (a GID not present in /etc/group).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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
A file with no valid group owner (its GID does not map to any entry in /etc/group) is not a direct vulnerability, but it is a strong signal that something is wrong: leftover files from a deleted account, a botched software install or removal, or an intruder's artifacts. Worse, if a new group is later created and reuses that GID, it silently inherits access to the orphaned files. Files should be repaired and the root cause investigated.
What Pavois checks
Pavois runs find / -xdev -nogroup and expects empty output, any returned path is a file whose group GID maps to no group. The -xdev flag keeps the scan on the local filesystem. Resolving GIDs against the live /etc/group (rather than a static report) catches orphans left by recently deleted accounts and files extracted from foreign archives, which no config-file audit would surface.
describe command("timeout 90 find / -xdev -nogroup -not -path '/var/lib/private/*' -not -path '/var/cache/private/*' 2>/dev/null") do
its('exit_status') { should_not cmp 124 } # timeout killed the scan: no evidence, not a pass
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run the scan manually:
find / -xdev -nogroup
Expected output: nothing (empty). For each printed path, check the raw GID with stat -c '%g %n' <file> and assign a valid group with chgrp <group> <file> once you understand why it was orphaned.
Inspect & investigate
List offenders with their raw GID using find / -xdev -nogroup -printf '%G %p\n'. Cross-reference any reused GID against getent group. There is no dedicated log; group reassignments are recorded only if an auditd watch on chgrp is configured.
Remediation
No automated harden plan is defined for this rule, so it must be applied manually. Do not blindly reassign: first investigate why each file is group-orphaned (deleted account, bad install, intrusion). Once understood, give it a valid group with chgrp <group> <file>, or remove the file if it is genuine leftover debris.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | find / -xdev -nogroup 2>/dev/null # chgrp <group> <path> per item after review |
|---|---|
| reason | an ungroup-owned file signals a deleted group, assign a group deliberately |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if left as-is: a future group created with the same GID silently gains access to these files, and the orphans may mask intrusion artifacts. Before fixing: a group-orphaned file can be evidence, preserve it for investigation before changing it. Avoid a blanket chgrp to a single group, which could grant unintended access; assign the correct owning group case by case and delete only confirmed debris.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R53 | direct | 2.0 | high |
| CIS | 2.2.6, 7.1.12 | 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.