← Toutes les règles
SOCLE-CLD-FSP-136// File permissionsmoyenneétat d’inventaire

Vérifier les permissions du fichier gshadow

Garantit que /etc/gshadow est illisible et non modifiable par tous (propriétaire compris) et exempt de tout bit exécutable/setuid/setgid/sticky (mode attendu 0000 root:root).

Vérifié sur ce qui est installé ou enregistré, paquets présents/absents, bases de comptes.

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 de mots de passe de groupe et les listes d'administrateurs de groupe. Si un compte autre que root peut le lire, ces hachages deviennent une cible pour le cassage hors-ligne ; s'il est modifiable, un attaquant peut s'octroyer l'administration ou l'appartenance d'un groupe. Il doit être en 0000 root:root (aucune lecture ni écriture pour personne, même le propriétaire), le noyau autorise toujours l'accès à root. Cela garde les secrets de groupe confidentiels et le fichier inaltérable.

Ce que vérifie Pavois

Pavois lit les permissions réelles de l'inode /etc/gshadow avec la ressource InSpec file (un stat), sous only_if. Contrairement à la plupart des fichiers, elle interdit même la lecture/écriture du propriétaire : le mode sécurisé est 0000 root:root, root y accédant via son privilège de superutilisateur. Tout bit de lecture ou d'écriture pour le propriétaire, le groupe ou les autres, ou un bit spécial, fait échouer la règle. Vérifier les permissions réelles détecte une dérive qu'un contrôle de défaut de paquet manquerait.

only_if { file('/etc/gshadow').exist? }
describe file('/etc/gshadow') do
  it { should_not be_executable.by('owner') }
  it { should_not be_setuid }
  it { should_not be_executable.by('group') }
  it { should_not be_writable.by('group') }
  it { should_not be_setgid }
  it { should_not be_executable.by('other') }
  it { should_not be_writable.by('other') }
  it { should_not be_readable.by('other') }
  it { should_not be_sticky }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%a %U %G' /etc/gshadow. La sortie attendue est le mode 0 appartenant à root root, soit 0 root root (certaines distributions affichent 000). Tout bit de lecture ou d'écriture fait échouer la règle.

Inspecter et investiguer

Les opérations sur les mots de passe de groupe passent par gpasswd, qui consigne dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL). Confirmez les permissions avec stat /etc/gshadow. Si auditd surveille /etc/gshadow, les accès et modifications apparaissent dans /var/log/audit/audit.log.

Remédiation

Aucune remédiation automatique n'est définie ; appliquez-la manuellement : chmod 0000 /etc/gshadow && chown root:root /etc/gshadow. Aucun redémarrage de service n'est nécessaire ; gpasswd et consorts fonctionnent toujours en root malgré le mode 0000.

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

mode0640
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

Le mode 0000 root:root est sûr : les outils qui lisent /etc/gshadow (gpasswd, newgrp) sont setuid-root ou s'exécutent en root et contournent le mode vide. Aucun risque de blocage. Précaution : conservez le propriétaire root, un mauvais propriétaire combiné à 0000 ferait échouer même les outils légitimes. Laisser le fichier lisible expose les hachages de mots de passe de groupe au cassage hors-ligne.

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