Vérifier que seul root possède l'UID 0
Garantit que root est le seul compte avec l'UID 0 dans /etc/passwd.
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
Un compte dispose de toute l'autorité de root dès que son UID vaut 0, quel que soit son nom. Un second compte UID 0 est une porte dérobée cachée : il donne le contrôle total, multiplie la surface d'attaque par devinette de mot de passe sur un accès privilégié et casse la traçabilité, car les actions ne peuvent plus être attribuées à un administrateur unique. Plusieurs administrateurs doivent partager l'accès root via sudo, qui est journalisé par utilisateur.
Ce que vérifie Pavois
Pavois exécute une requête awk sur /etc/passwd et liste tout compte dont l'UID vaut 0 mais dont le nom n'est pas root. Le contrôle réussit uniquement si cette liste est vide. Inspecter la base de comptes résolue (plutôt que de se fier à un nom) détecte un super-utilisateur renommé ou dupliqué qu'un simple grep root laisserait passer.
describe command('awk -F: \'($3==0 && $1!="root"){print $1}\' /etc/passwd') do
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez awk -F: '($3==0 && $1!="root"){print $1}' /etc/passwd. Sortie attendue : rien (résultat vide). Tout nom affiché est un compte UID 0 supplémentaire à supprimer ou à réaffecter à un UID non nul.
Inspecter et investiguer
- Lister tous les comptes UID 0 :
awk -F: '$3==0{print $1}' /etc/passwd - Inspecter un compte suspect :
getent passwd <nom> - Les événements d'accès privilégié apparaissent dans
/var/log/auth.log(Debian/Ubuntu) ou/var/log/secure(famille RHEL).
Remédiation
Aucune remédiation automatique n'est fournie : supprimer ou renuméroter un compte UID 0 est trop destructeur pour être appliqué à l'aveugle. Corrigez manuellement, supprimez le compte indu (userdel) ou affectez-lui un UID unique non nul avec usermod -u <nouvel_uid> puis ré-attribuez ses fichiers, puis relancez le scan.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | # List accounts with uid 0 other than root; remove/fix each ONLY after confirming it is rogue. awk -F: '($3==0 && $1!="root"){print $1}' /etc/passwd # for a confirmed rogue account: userdel <name> (irreversible, verify it is not legitimate) |
|---|---|
| reason | deleting an account is irreversible, a human must confirm it is rogue |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un second compte UID 0 équivaut à une porte dérobée root non détectée : compromission totale du système et perte de traçabilité. Avant de corriger, vérifiez que le compte n'est pas une identité de service légitime et documentée ; sauvegardez /etc/passwd, /etc/shadow et /etc/group ; et assurez-vous qu'il reste au moins un accès root fonctionnel pour ne pas vous verrouiller.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.4.2.1, 8.2.1 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.1, AC-6(5), IA-2, IA-4(b) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 8.2.1 | 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.