S'assurer que les utilisateurs se ré-authentifient pour l'élévation de privilèges - sudo
S'assure qu'aucune directive !authenticate ne figure dans la politique sudoers, afin que chaque élévation de privilèges via sudo exige que l'utilisateur ressaisisse son mot de passe.
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
Une règle !authenticate (ou NOPASSWD) autorise l'élévation de privilèges sans ré-authentification. Si une session reste déverrouillée ou est détournée, toute personne présente, ou un processus malveillant dans cette session, peut exécuter des commandes root en silence. Exiger la ré-authentification confirme que l'utilisateur qui élève ses droits est bien le légitime et l'autorisé, et produit un enregistrement d'authentification pour la traçabilité.
Ce que vérifie Pavois
Pavois recherche dans l'arborescence sudoers active, /etc/sudoers et chaque fichier sous /etc/sudoers.d/, et la règle ne passe que si aucune directive !authenticate non commentée n'est présente. Comme sudo fusionne le fichier principal avec tous les drop-ins, parcourir toute l'arborescence détecte une exemption cachée dans n'importe quel drop-in, reflétant la politique effective et non un seul fichier.
describe command('grep -rqE \'^[^#]*\bNOPASSWD\b\' /etc/sudoers /etc/sudoers.d/ 2>/dev/null && echo ko || echo ok') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Exécutez sudo grep -rE '^[^#]*!authenticate' /etc/sudoers /etc/sudoers.d/. Le résultat attendu est aucune sortie, toute ligne correspondante contourne la ré-authentification et doit être supprimée.
Inspecter et investiguer
Sur AlmaLinux, les événements d'authentification de sudo sont journalisés dans /var/log/secure et via journalctl -t sudo. Avec la ré-authentification imposée, chaque élévation produit un enregistrement d'authentification ; une règle NOPASSWD/!authenticate laisserait la commande journalisée mais sans événement d'authentification.
Remédiation
Cette règle n'a pas de plan de durcissement automatisé dans Pavois ; elle doit donc être corrigée manuellement : trouvez le fichier fautif avec le grep ci-dessus, puis supprimez ou commentez la directive !authenticate / NOPASSWD (édition via visudo ou visudo -f /etc/sudoers.d/<fichier> afin que la modification soit validée syntaxiquement avant l'enregistrement).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | # Remove NOPASSWD so sudo always authenticates. WARNING: breaks any automation relying on passwordless # sudo (including pavois's own management user), repoint it to a key/password FIRST. grep -rl 'NOPASSWD' /etc/sudoers /etc/sudoers.d/ 2>/dev/null # then edit each with: visudo (or visudo -f /etc/sudoers.d/<file>) and delete the NOPASSWD tag |
|---|---|
| reason | dropping NOPASSWD breaks passwordless automation (incl. pavois), repoint it first |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Exiger un mot de passe pour des commandes auparavant sans mot de passe casse les automatisations sans surveillance (tâches cron, runners CI, scripts) qui dépendaient d'un sudo NOPASSWD. Avant d'appliquer, localisez ces appelants automatisés et migrez-les vers un compte de service dédié avec une règle NOPASSWD strictement limitée à une commande précise, plutôt que de laisser une exemption globale pour les utilisateurs interactifs.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.2.4 | direct | per OS, see the benchmark table | haute |
| NIST | IA-11, 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.