Exiger une réauthentification lors de l'utilisation de la commande sudo
Interdit Defaults timestamp_timeout=-1 dans sudoers. La valeur -1 fait que le cache d'authentification de sudo n'expire jamais : l'utilisateur s'authentifie une fois et n'est plus jamais sollicité pendant toute la vie du terminal. Le retirer rétablit la fenêtre de réauthentification par défaut de sudo, soit 15 minutes.
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 réauthentification, des utilisateurs peuvent accéder à des ressources ou effectuer des tâches pour lesquelles ils ne sont pas autorisés. Lorsqu'un système d'exploitation offre la possibilité d'élever ses privilèges, il est essentiel que l'utilisateur se réauthentifie.
Ce que vérifie Pavois
Pavois exécute grep -rqE 'timestamp_timeout[[:space:]]*=[[:space:]]*-1' /etc/sudoers /etc/sudoers.d/ : une correspondance donne ko (échec), aucune correspondance donne ok (réussite). Le grep est récursif sur le répertoire de drop-ins : un -1 dissimulé dans un fichier de /etc/sudoers.d/ est donc détecté, là même où sudo le lirait. Le contrôle ne rejette que la valeur sentinelle -1 : le défaut intégré comme tout délai positif explicite passent. La preuve est de type persistent-config car sudo n'a pas de démon interrogeable : la politique est analysée à chaque invocation.
describe command('grep -rqE \'timestamp_timeout[[:space:]]*=[[:space:]]*-1\' /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 'timestamp_timeout' /etc/sudoers /etc/sudoers.d/ : aucune ligne ne doit fixer la valeur à -1 (une sortie vide est une réussite). Testez ensuite le comportement :
sudo -k # invalide l'authentification en cache
sudo -v # doit demander le mot de passe
sudo -v # aucune demande : le cache est chaud
Une fois le délai écoulé, sudo -v doit redemander le mot de passe. S'il ne le fait jamais, un -1 reste actif quelque part.
Inspecter et investiguer
sudo écrit ses événements d'authentification dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL), accessibles via journalctl -t sudo. Un échec de saisie apparaît ainsi :
sudo: pam_unix(sudo:auth): authentication failure; logname=alice uid=1000 euid=0 tty=/dev/pts/0 ruser=alice rhost= user=alice
Attention à l'angle mort que cette règle referme : la réutilisation de l'authentification en cache ne produit aucune entrée de journal. Ce cache est un fichier d'horodatage sous /run/sudo/ts/<utilisateur> et, avec timestamp_timeout=-1, les commandes d'un attaquant n'apparaîtraient que sous forme de lignes COMMAND= ordinaires, sans jamais d'événement d'authentification les précédant. Si sudo-custom-logfile est appliquée, ces mêmes lignes de commande sont aussi écrites dans /var/log/sudo.log.
Remédiation
Le plan Pavois est manuel à dessein (resource: manual, motif : sudoers edits risk lockout, always edit via visudo). Il signale les fichiers fautifs avec grep -rl 'timestamp_timeout[[:space:]]*=[[:space:]]*-1' /etc/sudoers /etc/sudoers.d/ ; vous retirez ensuite la ligne timestamp_timeout=-1 de chacun avec visudo (visudo pour le fichier principal, visudo -f /etc/sudoers.d/<fichier> pour un drop-in). Sudo revient à son défaut de 15 minutes dès que la ligne disparaît. Aucune écriture automatisée, aucun service à recharger.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | grep -rl 'timestamp_timeout[[:space:]]*=[[:space:]]*-1' /etc/sudoers /etc/sudoers.d/ 2>/dev/null # remove the 'timestamp_timeout=-1' line from each with visudo (default is 15min re-auth) |
|---|---|
| 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
Avec timestamp_timeout=-1, une seule saisie de mot de passe couvre toute la session : quiconque s'empare d'un terminal ouvert, d'un poste déverrouillé ou d'une session SSH détournée exécute des commandes root sans jamais rencontrer d'invite, et l'exigence de réauthentification (NIST IA-11) est vidée de sa substance. Appliquer le correctif rétablit simplement les invites ; le coût opérationnel se limite à davantage de saisies pour les administrateurs enchaînant de longs traitements, ce que sudo -v (rafraîchissement du cache) ou un délai positif raisonnable règle, jamais -1. Le vrai risque est la modification elle-même : une erreur de syntaxe dans sudoers coupe l'accès root à tout le monde. Utilisez toujours visudo, qui refuse d'enregistrer un fichier invalide, et gardez une seconde session root ouverte jusqu'à avoir confirmé que sudo -v fonctionne encore.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.2.6 | direct | per OS, see the benchmark table | haute |
| NIST | IA-11 | 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.