sudo : déléguer des droits sans donner les clés du camion

À quoi sert sudo ?

sudo permet d’autoriser certains utilisateurs à exécuter certaines commandes avec des droits élevés, sans leur donner le mot de passe root ni ouvrir la porte de la salle des machines avec un badge “servez-vous”.

C’est un outil de délégation.

Pas une baguette magique.

Les trois pièces importantes

• sudo : la commande utilisée par l’utilisateur ;
• /etc/sudoers : le fichier de règles ;
• visudo : l’éditeur sécurisé qui vérifie la syntaxe.

Règle simple :

sudo visudo

ou mieux, créer un fichier dédié :

sudo visudo -f /etc/sudoers.d/mon-equipe

Éviter d’éditer /etc/sudoers directement avec un éditeur classique. Une erreur de syntaxe peut verrouiller l’administration. C’est une façon très rapide de transformer une journée normale en exercice de récupération.

Exemple moderne simple

Autoriser les membres du groupe admin-web à redémarrer Nginx :

%admin-web ALL=(root) /bin/systemctl restart nginx, /bin/systemctl reload nginx

C’est précis :

• qui : %admin-web ;
• où : ALL ;
• en tant que qui : root ;
• quoi : deux commandes exactes.

Éviter le piège du ALL partout

Facile :

groot ALL=(ALL) NOPASSWD: ALL

Pratique ? Oui.

Bon signe ? Pas vraiment.

C’est parfois acceptable sur une machine personnelle ou un lab. En production, ça doit être justifié, limité et audité.

Groupes et fichiers dédiés

Créer un groupe :

sudo groupadd admin-web
sudo usermod -aG admin-web groot

Puis une règle :

sudo visudo -f /etc/sudoers.d/admin-web

Contenu :

%admin-web ALL=(root) /bin/systemctl reload nginx, /bin/journalctl -u nginx

Bonnes pratiques

• utiliser des groupes plutôt que des utilisateurs isolés ;
• écrire des chemins complets de commandes ;
• éviter NOPASSWD sauf besoin réel ;
• limiter les commandes ;
• journaliser ;
• tester dans une deuxième session root ouverte avant de fermer la première ;
• documenter pourquoi la règle existe.

Vérifier les droits

Pour voir ce qu’un utilisateur peut faire :

sudo -l

Pour tester une règle :

sudo -u utilisateur sudo -l

selon contexte et droits disponibles.

Attention aux commandes trop larges

Autoriser un éditeur, un shell, less, vim, find -exec, tar, python, ou bash avec sudo revient souvent à donner root indirectement.

Exemple dangereux :

user ALL=(root) /usr/bin/vim

Depuis vim, on peut lancer un shell. Surprise : ce n’était pas une délégation fine, c’était root avec moustache.

Verdict

sudo reste un outil fondamental. La règle d’or : donner le minimum utile, à un groupe clair, dans un fichier dédié, avec une raison documentée.

Le reste, c’est du folklore d’admin pressé. Et le folklore finit souvent dans /var/log/auth.log.