Vérifier que tous les fichiers appartiennent à un groupe
Garantit qu'aucun fichier d'un système de fichiers local n'a un groupe propriétaire non attribué (un GID absent de /etc/group).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Un fichier sans groupe propriétaire valide (son GID ne correspond à aucune entrée de /etc/group) n'est pas une vulnérabilité directe, mais c'est un signal fort d'anomalie : restes d'un compte supprimé, installation ou désinstallation logicielle bâclée, ou artefacts d'un intrus. Pire, si un nouveau groupe est créé plus tard en réutilisant ce GID, il hérite silencieusement de l'accès aux fichiers orphelins. Les fichiers doivent être réparés et la cause racine investiguée.
Ce que vérifie Pavois
Pavois lance find / -xdev -nogroup et attend une sortie vide : tout chemin renvoyé est un fichier dont le GID de groupe ne correspond à aucun groupe. Le drapeau -xdev maintient l'analyse sur le système de fichiers local. Résoudre les GID par rapport au /etc/group réel (plutôt qu'un rapport statique) détecte les orphelins laissés par des comptes récemment supprimés et les fichiers extraits d'archives étrangères, qu'aucun audit de fichier de configuration ne révélerait.
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 '' }
endComment vérifier qu’elle est appliquée
Lancez l'analyse manuellement :
find / -xdev -nogroup
Sortie attendue : rien (vide). Pour chaque chemin affiché, vérifiez le GID brut avec stat -c '%g %n' <fichier> et attribuez un groupe valide avec chgrp <groupe> <fichier> une fois la cause de l'orphelinat comprise.
Inspecter et investiguer
Listez les fautifs avec leur GID brut via find / -xdev -nogroup -printf '%G %p\n'. Recoupez tout GID réutilisé avec getent group. Il n'y a pas de journal dédié ; les réattributions de groupe ne sont enregistrées que si une surveillance auditd sur chgrp est configurée.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement. Ne réattribuez pas aveuglément : recherchez d'abord pourquoi chaque fichier est orphelin de groupe (compte supprimé, mauvaise installation, intrusion). Une fois compris, donnez-lui un groupe valide avec chgrp <groupe> <fichier>, ou supprimez le fichier s'il s'agit de vrais débris résiduels.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| 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 localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque en l'état : un futur groupe créé avec le même GID obtient silencieusement l'accès à ces fichiers, et les orphelins peuvent masquer des artefacts d'intrusion. Avant de corriger : un fichier orphelin de groupe peut être une preuve, conservez-le pour investigation avant de le modifier. Évitez un chgrp global vers un seul groupe, qui pourrait accorder un accès non voulu ; attribuez le bon groupe propriétaire au cas par cas et ne supprimez que les débris confirmés.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R53 | direct | 2.0 | haute |
| CIS | 2.2.6, 7.1.12 | direct | per OS, see the benchmark table | haute |
| NIST | AC-6(1), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 2.2.6 | support | 4.0.1 | moyenne |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.