Vérifier que PAM impose les exigences de mot de passe : application à l'utilisateur root
Active enforce_for_root dans la configuration pwquality afin que la politique de mot de passe (longueur, classes de caractères, contrôles dictionnaire) soit également imposée à root. Sans elle, pam_pwquality se contente d'un avertissement lorsque root choisit un mot de passe faible, puis l'accepte.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
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
Un mot de passe complexe augmente le temps et les ressources nécessaires pour le compromettre. La complexité, ou robustesse, mesure la capacité d'un mot de passe à résister aux tentatives de devinette et aux attaques par force brute. Elle est l'un des facteurs qui déterminent le temps nécessaire pour casser un mot de passe : plus il est complexe, plus le nombre de combinaisons à tester avant compromission est élevé.
Ce que vérifie Pavois
Pavois recherche une directive enforce_for_root non commentée dans /etc/security/pwquality.conf et dans le répertoire de drop-ins /etc/security/pwquality.conf.d/, c'est-à-dire l'ensemble des fichiers réellement lus par libpwquality. Ne contrôler que le fichier principal manquerait la directive lorsqu'elle est livrée par un drop-in (et, à l'inverse, ne verrait pas celle qui y serait réintroduite). enforce_for_root est une directive booléenne : sa simple présence l'active, d'où un contrôle portant sur la clé et non sur une valeur.
describe command('grep -rqE \'^[[:space:]]*enforce_for_root\b\' /etc/security/pwquality.conf /etc/security/pwquality.conf.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Vérifiez que la directive est présente dans l'ensemble de configuration résolu :
grep -rE '^[[:space:]]*enforce_for_root' /etc/security/pwquality.conf /etc/security/pwquality.conf.d/
/etc/security/pwquality.conf.d/99-pavois.conf:enforce_for_root = 1
Le test effectif est comportemental : en tant que root, lancez passwd root et saisissez un mot de passe volontairement faible. Avec la directive active, il est refusé (BAD PASSWORD: The password is shorter than N characters) au lieu de faire l'objet d'un simple avertissement.
Inspecter et investiguer
Un refus est journalisé par PAM dans /var/log/auth.log (Debian/Ubuntu) ou via journalctl (famille RHEL) :
passwd[7788]: pam_pwquality(passwd:chauthtok): bad password: The password fails the dictionary check
Sans enforce_for_root, la même ligne apparaît pour root, mais le changement de mot de passe aboutit tout de même : le journal seul ne dit pas si la politique a été imposée, d'où l'importance du test comportemental ci-dessus.
Remédiation
Le plan de durcissement Pavois utilise une remédiation keyval qui écrit enforce_for_root = 1 dans son propre drop-in, /etc/security/pwquality.conf.d/99-pavois.conf, plutôt que de rapiécer le pwquality.conf de la distribution. La ressource est agrégée : Pavois réécrit ce drop-in avec l'ensemble des clés pwquality qu'il gère (minlen, minclass, difok, etc.), de sorte que le fichier porte toujours l'état désiré complet. Une clé ajoutée à la main dans 99-pavois.conf est donc écrasée à l'application suivante : placez vos propres surcharges dans un fichier drop-in distinct. Sur les distributions pilotées par authselect (famille RHEL), Pavois active en outre la fonctionnalité authselect correspondante pour que la pile PAM continue d'appeler pam_pwquality.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| file | /etc/security/pwquality.conf.d/99-pavois.conf |
|---|---|
| key | enforce_for_root |
| resource | keyval |
| value | 1 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Sans enforce_for_root, le compte le plus privilégié de la machine est le seul autorisé à choisir un mot de passe trivialement devinable, ce qui ruine toute la politique. L'activer n'a aucun effet sur les mots de passe existants et ne peut enfermer personne dehors : la contrainte ne porte que sur les changements de mot de passe à venir, effectués via PAM (passwd). Deux conséquences à anticiper. D'abord, une procédure d'urgence consistant à poser un mot de passe root simple sera désormais refusée : préparez à l'avance un mot de passe conforme. Ensuite, la directive ne couvre que le chemin PAM ; les changements scriptés qui le contournent (usermod -p, écriture directe d'une empreinte dans /etc/shadow) ne sont pas filtrés par pwquality : l'outillage de provisionnement doit appliquer la politique de son côté.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.3.3.2.8 | direct | per OS, see the benchmark table | haute |
| NIST | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | support | 800-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.