Vérifier le groupe propriétaire du fichier group
Garantit que le fichier /etc/group est détenu par le groupe root (gid 0).
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
Le fichier /etc/group définit chaque groupe du système et ses membres, et l'appartenance à un groupe confère des privilèges (par exemple sudo, wheel, docker, disk). Si le fichier est détenu par un groupe non privilégié, un de ses membres pourrait, combiné à des permissions trop ouvertes, s'ajouter à un groupe privilégié et obtenir un accès root ou équivalent. Restreindre la propriété de groupe à root (gid 0) garantit que seuls les comptes hautement privilégiés peuvent influencer l'appartenance aux groupes.
Ce que vérifie Pavois
Pavois lit le groupe propriétaire effectif de /etc/group sur le système en cours d'exécution via la ressource InSpec file et vérifie gid == 0. Il inspecte les métadonnées réelles de l'inode telles que le noyau les voit, et non une valeur par défaut de paquet : un fichier dont la propriété a dérivé après l'installation (ou après une restauration depuis une sauvegarde) est donc détecté.
only_if { file('/etc/group').exist? }
describe file('/etc/group') do
its('gid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/group. Sortie attendue : root 0. Tout autre nom de groupe ou gid non nul signifie que la règle n'est pas appliquée.
Inspecter et investiguer
Les changements de propriété ne sont pas journalisés par défaut. Surveillez le fichier avec auditd : auditctl -w /etc/group -p wa -k identity, puis examinez grep 'key="identity"' /var/log/audit/audit.log. Les modifications d'appartenance aux groupes effectuées via les outils sont aussi visibles dans /var/log/auth.log (Debian/Ubuntu) ou dans les entrées journalctl de groupadd/gpasswd/usermod.
Remédiation
Aucune remédiation automatique n'est définie pour cette règle ; elle doit donc être appliquée manuellement. Rétablissez le bon groupe propriétaire avec chgrp root /etc/group.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | root |
|---|---|
| path | /etc/group |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un groupe propriétaire autre que root sur /etc/group affaiblit la frontière de confiance autour de l'appartenance aux groupes, un levier connu d'élévation de privilèges. Rétablir la propriété root présente peu de risques : chgrp root ne change que la propriété de groupe, ni le contenu ni les permissions, et l'authentification continue de fonctionner. Précaution : ne videz, ne tronquez ni ne modifiez jamais les permissions de /etc/group en corrigeant la propriété, un fichier group corrompu peut casser sudo, la connexion et le démarrage des services ; conservez /etc/group en mode 0644 détenu par root:root.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
| CIS | 2.2.6, 7.1.3 | 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.