Vérifier le groupe propriétaire du fichier gshadow
Garantit que /etc/gshadow appartient au groupe GID 0 (root).
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
/etc/gshadow contient les mots de passe hachés des groupes. S'il appartient à un groupe autre que le GID 0 (ou le groupe dédié shadow sur Debian/Ubuntu), les membres de ce groupe pourraient lire les hachages et tenter de casser les mots de passe de groupe hors ligne, élevant leur accès. Restreindre l'appartenance de groupe maintient ces secrets sous le contrôle de root/shadow.
Ce que vérifie Pavois
Pavois demande à la ressource file le gid numérique résolu de /etc/gshadow et exige qu'il vaille 0. Le contrôle est ignoré si le fichier n'existe pas. Interroger directement l'appartenance de groupe effective du fichier (le gid résolu par le noyau) est exact et évite de deviner à partir d'un nom susceptible de varier selon les distributions.
only_if { file('/etc/gshadow').exist? }
describe file('/etc/gshadow') do
its('gid') { should eq 42 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/gshadow. Attendu : groupe root et gid 0 (sur Debian/Ubuntu, le groupe shadow est aussi acceptable selon la politique de la distribution). ls -l /etc/gshadow affiche également la colonne du groupe.
Inspecter et investiguer
- Inspecter la propriété :
stat -c '%U %G %a' /etc/gshadowouls -l /etc/gshadow. - Contrôle d'intégrité de la base gshadow :
grpck -r. - Si auditd surveille
/etc/gshadow, les modifications apparaissent dans/var/log/audit/audit.log.
Remédiation
Aucune remédiation automatique n'est fournie pour cette règle. Corrigez manuellement en définissant la bonne appartenance de groupe, par ex. chgrp 0 /etc/gshadow (ou chgrp shadow /etc/gshadow là où la distribution utilise le groupe shadow), puis relancez le scan.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | shadow |
|---|---|
| path | /etc/gshadow |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Une mauvaise appartenance de groupe de /etc/gshadow expose les hachages de mots de passe de groupe à un groupe non-root, permettant un cassage hors ligne et une élévation de privilèges. Le correctif chgrp est trivial et peu risqué ; appliquez simplement le gid attendu par votre distribution (0 sur la famille RHEL, souvent shadow sur Debian/Ubuntu) pour ne pas casser l'outillage local de mots de passe.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
| CIS | 7.1.7 | 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 |
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.