Exiger use_authtok pour pam_unix.so
Force pam_unix.so à réutiliser le jeton de mot de passe déjà validé par les modules de complexité, via l'option use_authtok dans la pile PAM password.
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
Sans use_authtok, le module pam_unix.so redemande un nouveau mot de passe au lieu de réutiliser le jeton déjà validé par les modules de complexité précédents (pam_pwquality / pam_cracklib). On obtient un mot de passe qui contourne les contrôles de robustesse, d'historique et de dictionnaire configurés, annulant silencieusement toute la politique de mot de passe.
Ce que vérifie Pavois
Pavois recherche dans la pile PAM password effective sous /etc/pam.d/ une ligne pam_unix.so non commentée portant use_authtok. Lire l'arborescence PAM réelle (y compris common-password et tout fichier de service qui l'inclut via @include) capte l'option là où elle est vraiment câblée, ce qu'un contrôle figé sur un seul fichier raterait.
describe command('grep -RqE \'^[^#]*\bpam_unix\\.so\b[^#]*\buse_authtok\' /etc/pam.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Exécutez :
grep -rE '^[^#]*\bpam_unix\.so\b[^#]*\buse_authtok' /etc/pam.d/
Attendu : au moins une ligne password (typiquement dans common-password ou password-auth) montre pam_unix.so suivi de use_authtok. Aucune correspondance signifie que l'option est absente.
Inspecter et investiguer
Les événements d'authentification et de changement de mot de passe PAM sont journalisés dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/Fedora). Suivez-les en direct avec journalctl -t passwd -f ou journalctl _COMM=passwd lors d'un changement de mot de passe ; un jeton rejeté par les modules de complexité y apparaît.
Remédiation
Aucun plan de durcissement automatisé n'est encore fourni pour cette règle : elle doit être appliquée manuellement. Éditez la pile password (/etc/pam.d/common-password sous Debian/Ubuntu, /etc/pam.d/password-auth et system-auth sous RHEL/Fedora, idéalement via authselect/pam-auth-update) et ajoutez use_authtok à la ligne pam_unix.so, après le module pam_pwquality.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | # Ensure pam_unix in /etc/pam.d/common-password carries 'use_authtok' (so it reuses the checked # password). Manage the stack with: pam-auth-update (do not hand-edit common-password) |
|---|---|
| reason | PAM password-stack change, apply via pam-auth-update, not a hand edit |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Si l'option n'est pas posée, des utilisateurs peuvent définir des mots de passe faibles qui échappent à la politique ; la correction en elle-même est peu risquée. Précautions : ne modifiez jamais à la main une pile PAM via votre unique session SSH sans garder un shell root ouvert en secours, une erreur d'ordonnancement sur pam_unix.so peut bloquer toute authentification par mot de passe. Privilégiez pam-auth-update/authselect, et vérifiez le changement dans une seconde session avant de fermer la première.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.3.3.4.4 | 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.