Vérifier l'utilisateur propriétaire du fichier de sauvegarde gshadow
Garantit que le fichier de sauvegarde /etc/gshadow- appartient à root (uid 0).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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- est la sauvegarde de /etc/gshadow et contient des empreintes de mots de passe de groupe. S'il n'appartient pas à root (uid 0), un utilisateur non autorisé pourrait lire ces empreintes et tenter un cassage hors-ligne, ou altérer la sauvegarde. Comme il contient du matériel d'identification, protéger ce fichier est critique pour la sécurité du système.
Ce que vérifie Pavois
Pavois lit l'uid propriétaire effectif du fichier avec la ressource InSpec file et vérifie qu'il vaut 0 (root), uniquement si le fichier existe. Lire le propriétaire réel du système de fichiers reflète la protection réellement appliquée, détectant la dérive de chown, au lieu de supposer que la valeur par défaut créée par les outils de gestion de groupes a été conservée.
only_if { file('/etc/gshadow-').exist? }
describe file('/etc/gshadow-') do
its('uid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U' /etc/gshadow-. Sortie attendue : root. Sinon, ls -l /etc/gshadow- doit afficher root dans la colonne du propriétaire.
Inspecter et investiguer
Le propriétaire est affiché par ls -l /etc/gshadow- et stat /etc/gshadow-. La sauvegarde est réécrite lors des changements de mots de passe de groupe (gpasswd, groupmod). Si auditd surveille /etc/gshadow- (surveillance standard des fichiers d'identité), les événements chown et d'écriture apparaissent dans /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle : elle doit être corrigée manuellement avec chown root /etc/gshadow- (souvent accompagné de chgrp shadow sur Debian/Ubuntu ou chgrp root sur RHEL, et chmod 0000/0600 pour correspondre à /etc/gshadow).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| owner | root |
|---|---|
| path | /etc/gshadow- |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Une propriété autre que root expose les empreintes de mots de passe de groupe à la lecture et au cassage hors-ligne, ou à l'altération, un risque sérieux de compromission d'identifiants. Rétablir la propriété root n'a aucun impact opérationnel ; seuls les outils de gestion de groupes touchent ce fichier. Précaution : si /etc/gshadow- est absent, le contrôle est ignoré ; relancez-le après le prochain changement de mot de passe de groupe. Évitez d'assouplir les permissions au-delà de celles de /etc/gshadow lui-même.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 7.1.8 | direct | per OS, see the benchmark table | haute |
| NIST | AC-6 (1) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 2.2.6 | 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.