Vérifier que PAM impose les exigences de mot de passe : application active
enforcing = 0 ne doit apparaître nulle part dans la configuration pwquality ni dans la pile PAM. Avec ce réglage, pam_pwquality bascule en mode consultatif : il signale bien un mot de passe faible, mais l'accepte, ce qui rend toute la politique de complexité purement décorative.
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. Avec enforcing=1, « pwquality » impose réellement les règles de construction des mots de passe et limite les attaques par force brute contre le système.
Ce que vérifie Pavois
Pavois recherche enforcing = 0 dans trois emplacements à la fois : /etc/security/pwquality.conf, les drop-ins de /etc/security/pwquality.conf.d/ et l'ensemble de la pile /etc/pam.d/, car l'option peut être posée soit comme directive de configuration, soit comme argument du module pam_pwquality.so sur la ligne password. Le contrôle ne passe que si la chaîne n'est trouvée nulle part : pwquality applique la politique par défaut, si bien que l'état conforme est l'absence de la directive, et non sa présence à 1. Un contrôle limité à pwquality.conf manquerait un enforcing=0 ajouté directement dans /etc/pam.d/common-password.
describe command('grep -RqE \'enforcing[[:space:]]*=[[:space:]]*0\' /etc/security/pwquality.conf /etc/security/pwquality.conf.d/ /etc/pam.d/ 2>/dev/null && echo ko || echo ok') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Relancez la même recherche sur les trois emplacements et attendez aucune sortie :
grep -RE 'enforcing[[:space:]]*=[[:space:]]*0' /etc/security/pwquality.conf /etc/security/pwquality.conf.d/ /etc/pam.d/
Confirmation comportementale : avec un utilisateur non privilégié, lancez passwd et proposez un mot de passe faible. Il doit être refusé (BAD PASSWORD: ... suivi d'une nouvelle invite), et non simplement signalé puis accepté.
Inspecter et investiguer
Les deux modes produisent la même ligne PAM dans /var/log/auth.log (Debian/Ubuntu) ou via journalctl (famille RHEL) :
passwd[8899]: pam_pwquality(passwd:chauthtok): bad password: The password is shorter than 14 characters
Le journal ne révèle donc pas si le mot de passe a été refusé ou seulement signalé : seul le résultat de la commande passwd distingue le mode consultatif (enforcing = 0, mot de passe changé malgré tout) de l'application effective (changement refusé).
Remédiation
Pavois classe cette remédiation en manuelle : le script livré se contente de lister les fichiers contenant enforcing = 0 (la même recherche à trois emplacements que le contrôle), et vous supprimez la ou les lignes fautives après analyse. Rien n'a besoin d'être ajouté à la place, puisque pwquality applique la politique dès que la directive est absente. Sur Debian et Ubuntu, si l'option figure sur la ligne pam_pwquality.so de /etc/pam.d/common-password, éditer ce fichier n'est pas durable : pam-auth-update le régénère à partir de /usr/share/pam-configs/ lors de la prochaine mise à niveau ou reconfiguration de libpam-runtime et peut réintroduire l'argument. Retirez-le du profil pam-config, ou de pwquality.conf, pour que le correctif survive à la régénération.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | grep -rl 'enforcing[[:space:]]*=[[:space:]]*0' /etc/security/pwquality.conf /etc/security/pwquality.conf.d/ /etc/pam.d/ 2>/dev/null # delete the 'enforcing = 0' line(s) so pwquality enforces (it does by default when absent) |
|---|---|
| reason | removing enforcing=0 makes pwquality reject weak passwords, verify your policy first |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Avec enforcing = 0, minlen, minclass et les contrôles dictionnaire ne sont que de la documentation : les utilisateurs continuent de choisir des mots de passe faibles, et un rapport de conformité fondé sur ces seules directives déclarerait à tort l'hôte durci. Rétablir l'application est peu risqué pour la disponibilité : les mots de passe existants restent valides, les sessions ne sont pas touchées et personne n'est enfermé dehors. La friction se produit au prochain changement de mot de passe, qui sera refusé tant qu'il ne satisfait pas la politique. Avant de retirer l'option, relisez la politique réellement en vigueur (grep -vE '^\s*#|^\s*$' /etc/security/pwquality.conf, ainsi que les drop-ins) pour ne pas confronter les utilisateurs à une règle inopinément stricte ; traitez enforce_for_root comme un sujet distinct, et prévenez les utilisateurs dont le mot de passe approche de l'expiration, car ils rencontreront la nouvelle règle en premier.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.3.3.2.7 | direct | per OS, see the benchmark table | haute |
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.