S'assurer que les utilisateurs se ré-authentifient pour l'élévation de privilèges - sudo !authenticate
S'assure qu'aucune directive !authenticate ne figure dans la politique sudoers, afin que chaque appel à 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) permet aux utilisateurs d'obtenir les droits root sans se ré-authentifier. Si leur session reste déverrouillée ou est détournée, quiconque devant le clavier, ou un processus malveillant dans cette session, peut exécuter des commandes privilégiées en silence. Exiger une ré-authentification garantit que la personne qui élève ses privilèges est bien l'utilisateur légitime et autorisé, et génère un événement 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 trouvée. 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 d'authentification effective et non un seul fichier.
describe command('grep -rqE \'^[^#]*!authenticate\' /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 est une règle contournant la ré-authentification et doit être supprimée.
Inspecter et investiguer
Les événements d'authentification de sudo sont journalisés dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL), et via journalctl -t sudo. Avec la ré-authentification imposée, chaque élévation produit un enregistrement d'invite/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 : localisez 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 | grep -rl '!authenticate' /etc/sudoers /etc/sudoers.d/ 2>/dev/null # remove the !authenticate directive from each with: visudo (or visudo -f /etc/sudoers.d/<file>) |
|---|---|
| reason | sudoers edits risk lockout, always edit via visudo |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Retirer NOPASSWD/!authenticate exigera un mot de passe pour les commandes concernées, ce qui casse les automatisations sans surveillance (tâches cron, runners CI, scripts) reposant sur un sudo sans mot de passe. Avant d'appliquer, identifiez ces appelants automatisés et déplacez-les vers un compte de service dédié avec une règle NOPASSWD strictement limitée à une commande précise, ou vers un runner gérant les secrets, 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.5, 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 |
| DISA STIG | UBTU-22-432010, UBTU-24-300021 | direct | per OS STIG release | 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.