Vérifier que seul le groupe root possède le GID 0
Garantit qu'aucun groupe autre que root ne possède le GID 0, empêchant l'aliasing du groupe privilégié.
Vérifié sur ce qui est installé ou enregistré, paquets présents/absents, bases de comptes.
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 GID 0 est celui du groupe privilégié root : les fichiers qu'il possède et de nombreuses opérations privilégiées dépendent du groupe root. Si un second groupe porte aussi le GID 0, il devient un alias du groupe root, ses membres et tout fichier qu'il possède en groupe sont traités comme appartenant au groupe root, accordant un accès censé être réservé. C'est une technique répandue d'élévation de privilèges et de porte dérobée, d'où la sévérité haute. Seul le groupe canonique root doit détenir le GID 0.
Ce que vérifie Pavois
Pavois parcourt chaque entrée de groupe (nom + GID) et affirme que le seul portant le GID 0 est root. Évaluer les entrées résolues plutôt que de supposer que /etc/group est l'unique source maintient le contrôle valide même lorsque les données de groupe proviennent en partie d'un autre backend NSS.
describe command('awk -F: \'($3==0 && $1!="root"){print $1}\' /etc/group') do
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Listez tout groupe non-root partageant le GID 0 :
awk -F: '($3==0 && $1!="root"){print $1}' /etc/group, la sortie attendue est vide.getent group 0, doit renvoyer uniquement la ligneroot:x:0:.
Inspecter et investiguer
La création/modification de groupes laisse une trace :
grep -E 'groupadd|groupmod' /var/log/auth.log(Debian/Ubuntu) //var/log/secure(RHEL), affiche l'ajout d'un groupe ou le changement de son GID.getent group 0est la sonde de référence pour l'état courant.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement : identifiez le groupe fautif avec getent group 0, puis réattribuez-lui un GID libre et non nul via groupmod -g <nouveaugid> <groupe>, et mettez à jour la possession de tout fichier qu'il possède en groupe avec find / -gid 0 -group <groupe> -exec chgrp <groupe> {} + après la renumérotation.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | awk -F: '($3==0 && $1!="root"){print $1}' /etc/group # groupmod -g <new-gid> <group> for each, manual |
|---|---|
| reason | a non-root group with GID 0 needs a deliberate renumber |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si non appliqué : un second groupe à GID 0 agit comme un équivalent root caché, permettant à ses membres ou à ses fichiers de contourner les restrictions prévues.
Précautions avant application : avant de renuméroter, inventoriez les fichiers possédés en groupe par le groupe fautif (find / -xdev -group <groupe>) ; après groupmod, vous devez chgrp ces fichiers vers le nouveau GID sinon ils deviennent orphelins. Ne réattribuez jamais le groupe root lui-même. Effectuez la modification dans une fenêtre de maintenance et vérifiez que les services privilégiés dépendant du groupe root démarrent toujours.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.4.2.3 | direct | per OS, see the benchmark table | haute |
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.