Tous les GID référencés dans /etc/passwd doivent exister dans /etc/group
Garantit que chaque GID principal référencé dans /etc/passwd est réellement défini dans /etc/group.
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
Chaque GID principal attribué à un utilisateur dans /etc/passwd doit correspondre à un groupe existant dans /etc/group. Un GID orphelin est une fuite de privilèges latente : si un administrateur crée plus tard un groupe portant ce même GID, l'utilisateur obtient silencieusement l'accès à tous ses fichiers et ressources sans aucune attribution explicite.
Ce que vérifie Pavois
Pavois extrait chaque GID principal distinct de /etc/passwd puis, pour chacun, interroge la base de groupes résolue avec getent group ; tout GID sans groupe correspondant est signalé. Le contrôle réussit uniquement si aucun n'est orphelin. L'utilisation de getent consulte la résolution de groupes effective (y compris SSSD/LDAP), et pas seulement le fichier /etc/group.
describe command('awk -F: \'{print $4}\' /etc/passwd | sort -u | while read g; do getent group "$g" >/dev/null || echo "$g"; done') do
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez awk -F: '{print $4}' /etc/passwd | sort -u | while read g; do getent group "$g" >/dev/null || echo "$g"; done. Sortie attendue : rien. Tout GID affiché est référencé par un utilisateur mais non défini comme groupe.
Inspecter et investiguer
- Trouver les utilisateurs référençant un GID orphelin :
awk -F: -v g=<gid> '$4==g{print $1}' /etc/passwd. - Inspecter les définitions de groupes :
getent groupoucat /etc/group. - Contrôle d'intégrité :
grpcketpwck.
Remédiation
Aucune remédiation automatique n'est fournie. Corrigez manuellement : soit créez le groupe manquant (groupadd -g <gid> <nom>), soit réaffectez les utilisateurs concernés à un groupe valide (usermod -g <gid_valide> <utilisateur>), puis relancez le scan.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | awk -F: '{print $4}' /etc/passwd | sort -u | while read g; do getent group "$g" >/dev/null || echo "missing group gid=$g"; done # groupadd -g <gid> <name> for each, or reassign the user's primary group |
|---|---|
| reason | a user's primary GID must exist in /etc/group, create the missing group deliberately |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
La mauvaise configuration est de faible gravité aujourd'hui mais devient une fuite de privilèges le jour où un groupe est créé avec un GID jusque-là orphelin. Avant de corriger, identifiez les utilisateurs portant le GID orphelin et décidez délibérément si le groupe doit exister ou si les utilisateurs doivent changer ; réaffecter le groupe principal d'un utilisateur modifie l'appartenance par défaut des fichiers qu'il créera ensuite.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 7.2.3, 8.2.2 | direct | per OS, see the benchmark table | haute |
| NIST | CM-6(a), IA-2 | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 8.2.2 | 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.