← Toutes les règles
SOCLE-CLD-FSP-077// File ownershipmoyenneétat du système de fichiers

Vérifier l'utilisateur propriétaire du fichier gshadow

Garantit que le fichier /etc/gshadow appartient à l'utilisateur root (UID 0).

Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 3 normes

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 stocke les hachages des mots de passe de groupe et les listes d'administrateurs de groupe. Si un utilisateur non root le possède, il pourrait lire les hachages pour un cassage hors ligne ou définir un mot de passe de groupe afin d'obtenir l'appartenance à un groupe privilégié via newgrp, une voie d'élévation de privilèges. La propriété par root est critique pour la sécurité du système.

Ce que vérifie Pavois

Pavois interroge l'inode réel de /etc/gshadow et vérifie que son propriétaire est l'UID 0. Lire les métadonnées réelles du système de fichiers reflète la propriété effective en vigueur, sur laquelle s'appuient les utilitaires shadow, et non une valeur par défaut de l'installateur.

only_if { file('/etc/gshadow').exist? }
describe file('/etc/gshadow') do
  its('uid') { should eq 0 }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%U %u' /etc/gshadow. La sortie attendue est root 0.

Inspecter et investiguer

Les changements de mots de passe de groupe via gpasswd sont consignés dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (famille RHEL). Pour détecter les éditions directes, posez une surveillance audit : auditctl -w /etc/gshadow -p wa -k gshadow, puis examinez /var/log/audit/audit.log (recherchez key="gshadow").

Remédiation

Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être corrigée manuellement : exécutez chown root /etc/gshadow pour rétablir la propriété root.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

ownerroot
path/etc/gshadow
resourcefile
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Un propriétaire non root de /etc/gshadow peut lire ou définir des hachages de mots de passe de groupe et élever ses privilèges. La correction est pratiquement sans risque : chown root /etc/gshadow ne modifie aucune entrée, l'authentification continue de fonctionner. Combinez-la avec des permissions strictes (chmod 0000 ou 0640 root:shadow selon la convention de la distribution) afin que les hachages ne soient pas lisibles. Le changement s'applique immédiatement.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R50direct2.0haute
CIS7.1.7directper OS, see the benchmark tablehaute
NISTAC-6(1), CM-6(a)support800-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.

Sources & références