Vérifier les permissions du fichier shadow
Garantit que /etc/shadow ne porte aucun accès en lecture/écriture/exécution pour le propriétaire, le groupe ou les autres ni aucun bit setuid/setgid/sticky, gardant les condensats de mots de passe hors de portée de tout compte.
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
/etc/shadow stocke les condensats de mots de passe de chaque compte local ainsi que les métadonnées de vieillissement. C'est l'un des fichiers les plus sensibles du système : tout accès en lecture par le groupe ou les autres expose les condensats au cassage hors ligne, et l'accès en écriture permet d'effacer un mot de passe ou d'injecter un condensat connu pour usurper un compte. Cette règle est stricte, elle interdit aussi les bits de lecture/écriture/exécution du propriétaire, car le fichier doit être médiatisé via l'outillage du groupe shadow, et non ouvert directement. Aucun bit setuid/setgid/sticky/exécutable n'a sa place ici. La protection effective de ce fichier est critique pour la sécurité du système.
Ce que vérifie Pavois
Pavois lit les bits de mode réels de /etc/shadow sur la cible, chaque bit de lecture/écriture/exécution propriétaire/groupe/autres plus setuid/setgid/sticky, directement depuis l'inode appliqué par le noyau, et non depuis une base documentée. Aucun include ni drop-in ne peut masquer un mode trop permissif. La garde only_if ignore le contrôle si le fichier est absent.
only_if { file('/etc/shadow').exist? }
describe file('/etc/shadow') 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 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%A %U %G' /etc/shadow. Attendu : mode ---------- (0000) sur Debian/Ubuntu appartenant à root shadow, ou 0000/0640 root root sur RHEL, dans tous les cas aucun bit de lecture/écriture pour le groupe ou les autres. Vérification rapide : find /etc/shadow -perm /7077 ne doit rien renvoyer.
Inspecter et investiguer
Les changements de permissions ne sont pas journalisés par défaut. Surveillez ce fichier critique avec auditd : auditctl -w /etc/shadow -p wa -k identity, puis consultez avec grep 'key="identity"' /var/log/audit/audit.log. Les changements de mot de passe et l'authentification utilisant ces condensats apparaissent dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL). Mode et propriété actuels : stat /etc/shadow.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle, elle doit donc être appliquée manuellement. Sur Debian/Ubuntu : chown root:shadow /etc/shadow && chmod 0640 /etc/shadow (le mode historique) ou 0000 ; sur RHEL : chown root:root /etc/shadow && chmod 0000 /etc/shadow. Le mode sécurisé exact dépend de la distribution, alignez-vous sur ce que livre l'éditeur de l'OS. Cela supprime toute lecture groupe/autres et tout bit setuid/setgid/sticky.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0640 |
|---|---|
| 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
Risque si mal réglé : un /etc/shadow lisible livre à chaque compte les condensats pour cassage hors ligne, la défaillance de permission de fichier la plus dommageable ; un /etc/shadow modifiable permet l'usurpation directe de compte. Appliquer le correctif est sûr car les outils privilégiés (passwd, login, PAM) accèdent au fichier en root ou via le groupe shadow, pas par des bits de lecture normaux. Précaution : ne le rendez pas lisible par tous et ne retirez pas la propriété du groupe shadow sur Debian/Ubuntu, passwd en dépend pour mettre à jour les condensats des utilisateurs non privilégiés.
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.