Éditer /etc/sudoers directement avec nano ou vim fonctionne, jusqu’au jour où une erreur de syntaxe casse sudo pour tout le monde, y compris pour la personne qui vient de faire l’erreur : sans sudo fonctionnel, corriger le fichier qui a cassé sudo exige un accès root déjà présent par un autre moyen, une situation qui n’existe pas toujours.

Ce que visudo fait de différent

visudo ouvre le fichier sudoers dans un éditeur, exactement comme n’importe quel éditeur classique, mais valide sa syntaxe avant d’écrire le fichier réel : une erreur de syntaxe bloque la sauvegarde et propose de corriger, sans jamais laisser un fichier sudoers invalide remplacer l’ancien.

# Valide la syntaxe avant d'écrire,
# contrairement à un éditeur classique sur le fichier direct
visudo
# >>> /etc/sudoers: syntax error near line 42 <<<
# What now? Options are:
#   (e)dit sudoers file again
#   e(x)it without saving changes to sudoers file

Cette validation élimine la classe d’incidents la plus dangereuse pour ce fichier précis : un sudo cassé pour l’ensemble du système, potentiellement irréversible sans accès physique ou console de secours à la machine.

Le piège du NOPASSWD trop large

NOPASSWD dans une entrée sudoers autorise l’exécution d’une commande sans redemander de mot de passe, une commodité qui devient un vrai risque de sécurité dès qu’elle s’applique à une portée trop large.

# Portée large : n'importe quelle commande, sans mot de passe,
# annule l'intérêt même d'exiger une authentification sudo
myuser ALL=(ALL) NOPASSWD: ALL
# Portée restreinte : une commande précise, sans mot de passe,
# le reste continue d'exiger une authentification normale
myuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart my-app

Un NOPASSWD: ALL accordé par commodité (souvent pour un script d’automatisation qui a besoin d’exécuter une seule commande) élimine la barrière d’authentification pour absolument tout, bien au-delà du besoin initial, une dérive qui survit rarement à un audit de sécurité une fois découverte — le même principe de moindre privilège qui s’applique au RBAC Kubernetes s’applique tout autant à un fichier sudoers.

Ce que les directives Defaults changent silencieusement

Les lignes Defaults du fichier sudoers modifient le comportement global de sudo, souvent sans que leur effet ne soit évident à la lecture.

# Conserve certaines variables d'environnement à travers sudo,
# un comportement non garanti par défaut selon la distribution
Defaults env_keep += "HOME EDITOR"

# Force un chemin de recherche de binaires spécifique,
# indépendamment du PATH de l'utilisateur qui invoque sudo
Defaults secure_path = "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"

secure_path en particulier empêche qu’un utilisateur avec un PATH personnel modifié (pointant vers un binaire malveillant nommé comme une commande système courante) ne fasse exécuter ce binaire avec les privilèges de sudo, une protection silencieuse mais réelle contre une classe d’attaque par détournement de PATH.

À retenir

visudo valide la syntaxe du fichier sudoers avant de l’écrire, éliminant le risque le plus dangereux pour ce fichier précis : un sudo cassé pour l’ensemble du système sans accès de secours pour le réparer. Un NOPASSWD accordé sur une portée trop large (ALL plutôt qu’une commande précise) annule l’intérêt même de l’authentification sudo, une dérive courante née d’un besoin d’automatisation ponctuel. Les directives Defaults comme secure_path modifient silencieusement le comportement de sudo de façon à fermer des classes entières d’attaques, des réglages qui restent pertinents quel que soit le niveau d’abstraction de l’infrastructure au-dessus des machines qui exécutent réellement ce fichier.