Politique sudo en fichiers drop-in dans /etc/sudoers.d, vérifiée avec visudo -c

Objectif

Accorder à un compte le privilège sudo le plus restreint possible, sous forme de fichier relisable, sans risquer de corrompre le fichier sudoers et de perdre l'accès administratif.

Prérequis

Un accès root, ou un compte sudo existant et fonctionnel ; connaître précisément la ou les commandes que le compte cible doit exécuter, ainsi que l'utilisateur sous l'identité duquel elles doivent l'être.

Étapes

1. Ne jamais modifier /etc/sudoers ni les fichiers de /etc/sudoers.d/ avec un éditeur ordinaire directement sur le fichier en production ; passer systématiquement par visudo, qui verrouille le fichier et valide la syntaxe avant l'enregistrement : visudo -f /etc/sudoers.d/deploy-restart.
2. Écrire la règle la plus restreinte qui répond au besoin : une commande précise, des arguments précis et un utilisateur cible précis, pas ALL : deploy ALL=(root) /usr/bin/systemctl restart myapp.service Éviter NOPASSWD:ALL ou une liste de commandes sans restriction : les deux permettent au bénéficiaire d'exécuter n'importe quoi en tant que root, y compris de modifier des fichiers pour s'accorder davantage de droits, ce qui annule l'intérêt de restreindre la règle. Si la cible de sudo est un script, le considérer comme la véritable frontière de privilège : tout ce que ce script peut être amené à faire s'exécute en root.
3. Soigner le nom du fichier : sudo ignore les fichiers de /etc/sudoers.d/ dont le nom se termine par ~ ou contient un ., si bien que deploy.conf est ignoré sans avertissement alors que deploy-restart est lu. Conserver le mode 0440, avec root comme propriétaire. Valider le fichier sans l'appliquer, ce qui est utile dans un déploiement non interactif ou scripté : visudo -c -f /etc/sudoers.d/deploy-restart effectue une validation de syntaxe en lecture seule et signale les erreurs sans ouvrir d'éditeur.
4. Vérifier que la règle est bien prise en compte, depuis le compte cible : sudo -l -U deploy liste ce que le compte est autorisé à exécuter ; sudo -u deploy sudo /usr/bin/systemctl restart myapp.service la met directement à l'épreuve.
5. Vérifier ce que sudo journalise réellement : par défaut, les appels sudo réussis comme échoués sont envoyés au journal système/syslog via la facility authpriv/auth ; les consulter avec journalctl -t sudo ou avec le journal de sécurité/de messagerie de la distribution.

Résultat attendu

visudo -c ne signale aucune erreur de syntaxe ; sudo -l -U deploy affiche exactement la commande prévue et rien de plus large ; le journal contient une entrée pour chaque utilisation.

Limites et base de vérification

Cette méthodologie s'appuie sur sudoers(5) et visudo(8). Pour annuler, supprimer le fichier drop-in (rm /etc/sudoers.d/deploy-restart) ; ne jamais supprimer le fichier de base /etc/sudoers lui-même. Comme visudo verrouille et valide, une erreur commise dans cet outil ne peut pas corrompre la politique active ; cette protection ne s'applique pas à un fichier modifié en dehors de visudo et seulement vérifié après coup. Il faut donc toujours créer ou modifier le contenu de sudoers via visudo -f, et non avec un éditeur séparé suivi d'une vérification par visudo -c.