Vérifier que root a le GID principal 0
Garantit que le groupe principal du compte root (4e champ de sa ligne /etc/passwd) est le GID 0.
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 compte root doit avoir le groupe principal GID 0 (le groupe root). Si le GID principal de root pointe vers un groupe partagé ou un groupe utilisateur, les fichiers créés par root héritent de ce groupe et deviennent accessibles à tous ses membres. Maintenir le GID principal de root à 0 garantit que les fichiers appartenant à root restent sous le contrôle exclusif du groupe root.
Ce que vérifie Pavois
Pavois utilise awk pour afficher la ligne /etc/passwd de root uniquement si son 4e champ (GID principal) n'est pas 0. Le contrôle réussit seulement si rien n'est affiché. Lire la base de comptes résolue confirme le groupe principal effectif au lieu de supposer une valeur par défaut.
describe command('awk -F: \'($1=="root" && $4!=0){print}\' /etc/passwd') do
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez awk -F: '($1=="root" && $4!=0){print}' /etc/passwd (ou id -g root, qui doit renvoyer 0). Attendu : sortie vide / 0. Toute ligne affichée signifie que le GID principal de root est incorrect.
Inspecter et investiguer
- Vérifier directement le groupe principal de root :
id rootougetent passwd root. - Auditer les fichiers mal groupés à cause d'un GID root erroné :
find / -user root ! -group root -ls(sous-ensemble, de nombreux résultats légitimes attendus). - Événements de compte/connexion :
/var/log/auth.logou/var/log/secure.
Remédiation
Aucune remédiation automatique n'est fournie. Corrigez manuellement avec usermod -g 0 root pour replacer le groupe principal de root sur le GID 0, puis relancez le scan pour confirmer.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | id -g root usermod -g 0 root # set root's primary GID to 0 (only if the audit flagged it) |
|---|---|
| reason | changing root's primary group is sensitive, confirm before applying |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un GID principal non nul pour root entraîne l'appartenance des fichiers créés par root à un groupe non-root, exposant potentiellement du contenu sensible à ses membres. Le correctif est peu risqué ; sauvegardez tout de même /etc/passwd au préalable et notez que les fichiers déjà créés conservent leur ancien groupe et peuvent nécessiter un re-groupement.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.4.2.2, 8.2.1 | direct | per OS, see the benchmark table | haute |
| 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.