Vérifier le groupe propriétaire du fichier shadow
Garantit que le fichier d'empreintes /etc/shadow appartient au groupe root (gid 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
Le fichier /etc/shadow stocke les empreintes des mots de passe de chaque compte local. Si son groupe propriétaire n'est pas root (gid 0), un groupe non privilégié pourrait obtenir un accès en lecture, exposant les empreintes à un cassage hors-ligne puis à la compromission des comptes. Restreindre le groupe à root est un prérequis aux permissions strictes (typiquement 0640 root:shadow ou 0000) qui gardent ces empreintes secrètes.
Ce que vérifie Pavois
Pavois lit l'identifiant de groupe réel du fichier via la ressource InSpec file('/etc/shadow') et vérifie gid == 0. Il s'appuie sur la propriété effective enregistrée par le système de fichiers (la valeur stat réellement appliquée), et non sur un manifeste de paquet ou un script de durcissement qui pourrait avoir dérivé, un chgrp manuel ou un post-install de paquet fautif est donc détecté immédiatement.
only_if { file('/etc/shadow').exist? }
describe file('/etc/shadow') do
its('gid') { should eq 42 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/shadow. Sortie attendue : root 0 (le nom de groupe peut être shadow sur certaines installations Debian/Ubuntu, vérifiez alors avec getent group shadow, mais cette règle impose le gid 0).
Inspecter et investiguer
Les changements de propriété ne sont pas journalisés par défaut. Avec la surveillance auditd activée (auditctl -w /etc/shadow -p wa -k identity), toute écriture ou modification d'attribut apparaît dans /var/log/audit/audit.log ; filtrez avec grep 'key="identity"' /var/log/audit/audit.log.
Remédiation
Aucune remédiation automatique n'est câblée pour cette règle ; elle doit être appliquée manuellement : chgrp 0 /etc/shadow (ou chgrp shadow /etc/shadow sur les systèmes utilisant le groupe shadow, en confirmant que le gid 0 est bien voulu). Relancez ensuite pavois harden verify.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | shadow |
|---|---|
| path | /etc/shadow |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Si le groupe est trop permissif, les empreintes de mots de passe peuvent fuir vers des comptes non-root et être cassées hors-ligne. Remettre le groupe à root ne présente quasiment aucun risque opérationnel, passwd, login, PAM et sudo accèdent à /etc/shadow en tant que root. Précautions : conservez le mode strict associé (0640/0000) et, sur Debian/Ubuntu, ne cassez pas la convention du groupe shadow utilisée par certains outils ; vérifiez avec getent group shadow avant toute modification.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
| CIS | 2.2.6, 7.1.5 | direct | per OS, see the benchmark table | haute |
| NIST | AC-6(1), CM-6(a) | 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.