Linux sans magie #15 — sudo : exécuter une commande avec plus de privilèges sans devenir root

Sous Linux, certaines opérations nécessitent des privilèges supérieurs à ceux d’un utilisateur ordinaire. La réponse la plus simple serait de travailler directement avec le compte root, mais ce choix donne alors beaucoup plus de pouvoir que nécessaire.

sudo permet une approche plus fine : autoriser un utilisateur à exécuter une commande déterminée comme root — ou comme un autre utilisateur — selon une politique d’autorisation.

L’objectif de cet article est de comprendre cette délégation et de construire un lab minimal où un utilisateur peut exécuter une seule commande précise avec des privilèges élevés, tout en vérifiant qu’une commande différente reste refusée.

Contexte et problème

Les articles précédents de la série ont progressivement enrichi le modèle de permissions Linux : droits rwx, propriétaire et groupe, ACL, SUID, SGID, Sticky Bit puis Linux capabilities.

Avec sudo, le problème change légèrement. Il ne s’agit plus seulement de déterminer ce qu’un fichier ou un processus peut faire. Il faut répondre à une question d’administration :

Quel utilisateur
peut exécuter
quelle commande
avec quelle identité cible ?

Dans une infrastructure réelle, cette distinction est importante. Un opérateur peut avoir besoin de consulter l’état d’un service, lancer une commande de maintenance précise ou exécuter une opération réservée à root, sans pour autant recevoir un shell root général.

Une politique trop large réduit fortement l’intérêt de la délégation. Le but n’est donc pas simplement de « faire fonctionner sudo », mais d’autoriser uniquement l’opération réellement nécessaire.

Concept ou architecture

sudo consulte une politique de sécurité avant d’exécuter une commande. Avec l’implémentation sudo upstream classique, la politique par défaut est généralement fournie par sudoers.

Lorsqu’aucun utilisateur cible n’est indiqué avec -u, la cible par défaut est root.

Le flux logique peut être représenté ainsi :

Utilisateur
    │
    │ sudo /chemin/commande arguments
    ▼
Politique sudoers
    │
    ├── règle correspondante ──> exécution avec l’identité autorisée
    │
    └── aucune règle ──────────> refus

Le fichier principal est traditionnellement /etc/sudoers. Des règles supplémentaires peuvent également être chargées depuis un répertoire tel que /etc/sudoers.d/, uniquement si la politique locale inclut effectivement ce répertoire.

Une règle simple suit la logique suivante :

utilisateur  hôte=(utilisateur_cible)  commande

Par exemple :

<LAB_USER> ALL=(root) /usr/bin/id -u

Cette règle ne signifie pas « <LAB_USER> est administrateur ». Elle signifie uniquement que cet utilisateur peut exécuter la commande /usr/bin/id -u avec l’identité root, sous réserve des autres paramètres de la politique.

Prérequis

Utilisez une VM ou une machine de laboratoire sur laquelle vous disposez déjà d’un compte administratif fonctionnel.

Vous aurez besoin de :

• sudo installé ;
• un compte administrateur capable de modifier la politique sudo ;
• un second compte de laboratoire, noté <LAB_USER> ;
• ce compte <LAB_USER> ne doit pas déjà disposer d’un accès sudo général, sinon le test négatif perd son intérêt ;
• une session administrative de secours doit rester ouverte pendant la modification.

Avant de commencer, identifiez les chemins réellement utilisés :

command -v sudo
command -v id
command -v visudo

Dans les exemples suivants, nous supposons que id se trouve dans /usr/bin/id. Si votre système retourne un autre chemin, utilisez le chemin observé localement dans la règle.

Mise en pratique

1. Observer les droits sudo du compte de laboratoire

Connectez-vous avec <LAB_USER> et demandez la liste des privilèges que la politique lui accorde :

sudo -l

Cette commande constitue un point de comparaison avant modification.

Si <LAB_USER> possède déjà une règle très large, par exemple un droit d’exécuter toutes les commandes comme root, n’utilisez pas ce compte pour ce lab. Il serait impossible de démontrer qu’une commande non prévue reste réellement interdite.

2. Vérifier que /etc/sudoers.d est bien inclus

Avant de créer un fichier dans /etc/sudoers.d/, vérifiez que ce répertoire est effectivement chargé par la politique locale.

Commencez par afficher les directives d’inclusion du fichier principal :

sudo grep -nE '^[[:space:]]*([@#]include|[@#]includedir)[[:space:]]+' /etc/sudoers

Sur de nombreux systèmes utilisant sudoers, vous verrez une directive qui inclut /etc/sudoers.d, par exemple une forme équivalente à :

@includedir /etc/sudoers.d

ou, selon la syntaxe utilisée par la version installée :

#includedir /etc/sudoers.d

Ne poursuivez avec le chemin /etc/sudoers.d/m2si-sudo-lab que si /etc/sudoers.d est réellement inclus par votre politique.

Si aucun répertoire d’inclusion n’est configuré, n’ajoutez pas arbitrairement une directive à /etc/sudoers pour les besoins de ce lab. Utilisez plutôt un environnement de test dont la politique prévoit déjà un fichier ou un répertoire d’inclusion géré avec visudo.

3. Créer une règle isolée avec visudo

Lorsque l’inclusion de /etc/sudoers.d a été confirmée, éditez un fichier dédié :

sudo visudo -f /etc/sudoers.d/m2si-sudo-lab

Ajoutez une seule ligne en remplaçant <LAB_USER> par le nom du compte de laboratoire :

<LAB_USER> ALL=(root) /usr/bin/id -u

L’intérêt d’utiliser visudo est important : l’outil verrouille le fichier pendant l’édition et effectue des contrôles de syntaxe avant de valider la modification.

Évitez de modifier directement /etc/sudoers avec un éditeur ordinaire pour ce lab.

4. Valider la politique avant le test

Toujours depuis le compte administratif :

sudo visudo -c

Le résultat attendu est une validation sans erreur de syntaxe.

Si une erreur apparaît, corrigez-la avant de fermer votre session administrative de secours.

5. Vérifier la règle effective

Revenez dans la session <LAB_USER> puis exécutez :

sudo -l

La sortie doit maintenant montrer une autorisation correspondant à /usr/bin/id -u.

L’affichage exact dépend de l’implémentation et de la configuration locale, mais le point à vérifier est simple : la commande prévue doit apparaître comme autorisée.

6. Tester la commande autorisée

Exécutez :

sudo /usr/bin/id -u

Résultat attendu

La commande id -u affiche l’UID effectif du processus. Lorsqu’elle est exécutée comme root, le résultat attendu est :

0

Ce test montre que la commande précise autorisée s’exécute avec l’identité cible attendue.

Il ne signifie pas que <LAB_USER> est devenu root pour toute sa session.

7. Effectuer un test négatif

Testez maintenant une commande différente :

sudo /usr/bin/id

Même si le chemin du programme est identique, les arguments ne sont plus les mêmes que dans la règle du lab.

Avec une politique sudoers qui ne donne aucun autre privilège à <LAB_USER>, cette commande doit être refusée.

Ce second test est essentiel : vérifier uniquement que l’action autorisée fonctionne ne prouve pas que la règle est suffisamment restrictive.

Vérification

Le lab est validé lorsque les cinq observations suivantes sont réunies :

/etc/sudoers inclut sudoers.d → inclusion confirmée
sudo visudo -c              → politique valide
sudo -l                     → règle précise visible
sudo /usr/bin/id -u         → résultat 0
sudo /usr/bin/id            → refus attendu

Si la dernière commande fonctionne malgré tout, vérifiez les autres règles accordées au compte avec sudo -l. Une autorisation plus large peut déjà exister dans la politique.

Bonnes pratiques

Commencez par définir l’opération réellement nécessaire avant d’écrire la règle. Donner accès à une commande précise est généralement préférable à ouvrir immédiatement un accès ALL.

Utilisez des chemins absolus pour les commandes déclarées dans sudoers et vérifiez-les sur le système concerné avec command -v.

Conservez les règles spécifiques dans des fichiers dédiés lorsqu’un répertoire d’inclusion sudoers est configuré. Cela simplifie la lecture, la gestion de configuration et le rollback par rapport à l’accumulation de modifications dans un seul fichier principal.

Après chaque changement, combinez validation syntaxique et test fonctionnel. visudo -c confirme la cohérence de la politique ; il ne prouve pas à lui seul que la règle accorde exactement ce que vous vouliez.

Enfin, testez à la fois le cas autorisé et un cas qui doit rester interdit.

Sécurité

sudo est une frontière de privilèges. Une règle qui semble étroite peut devenir très puissante si la commande autorisée permet elle-même d’exécuter d’autres programmes, d’ouvrir un shell ou de modifier des fichiers sensibles.

Les éditeurs, interpréteurs de commandes, shells et certains outils extensibles demandent donc une attention particulière. Autoriser /bin/bash, par exemple, revient pratiquement à fournir un shell avec l’identité cible.

Le mot-clé ALL est également à manier avec prudence. Dans sudoers, il correspond à un alias intégré qui fait correspondre toutes les valeurs du contexte concerné. Il est utile dans certaines politiques, mais ne doit pas remplacer la réflexion sur le moindre privilège.

NOPASSWD ne doit pas non plus être ajouté uniquement pour rendre un lab ou un script plus pratique. La suppression de l’authentification interactive modifie le modèle de sécurité et doit répondre à un besoin explicite.

Coûts

Ce lab ne nécessite aucun service payant.

Il peut être réalisé sur une VM Linux locale ou tout autre environnement de test déjà disponible. Le coût éventuel dépend uniquement de l’infrastructure utilisée pour héberger cette VM.

Limites et points de vigilance

L’écosystème sudo dépend de la distribution et de l’implémentation installée. Ubuntu récent peut notamment utiliser sudo-rs comme fournisseur, sujet déjà traité séparément sur le blog.

Cet article vise le modèle de délégation et une règle sudoers simple. Il ne couvre pas les différences fonctionnelles complètes entre sudo.ws et sudo-rs, les politiques stockées dans LDAP, PAM en profondeur, la journalisation I/O distante ni les syntaxes sudoers avancées.

Les exemples supposent également que la politique du compte <LAB_USER> ne contient pas d’autre autorisation plus large. sudo -l reste donc indispensable avant d’interpréter le résultat d’un test.

Rollback ou nettoyage

Avant de supprimer la règle, gardez votre session administrative ouverte et vérifiez le fichier concerné :

sudo cat /etc/sudoers.d/m2si-sudo-lab

Si son contenu correspond bien uniquement au lab, supprimez ce fichier :

sudo rm /etc/sudoers.d/m2si-sudo-lab

Validez immédiatement la politique restante :

sudo visudo -c

Puis, depuis <LAB_USER> :

sudo -l

L’autorisation ajoutée par le lab ne doit plus apparaître.

Ne fermez la session administrative de secours qu’après cette vérification.

Références officielles

• sudo(8) — execute a command as another user — sudo project, copie du manuel upstream
• sudoers(5) — default sudo security policy plugin — sudo project, copie du manuel upstream
• visudo(8) — edit the sudoers file — sudo project, copie du manuel upstream
• User management — Canonical Ubuntu Server documentation

Conclusion

sudo n’est pas simplement un raccourci pour « devenir root ». C’est un mécanisme de délégation : une politique décide qui peut lancer quelle commande avec quelle identité.

Le bon réflexe consiste à partir d’un besoin précis, écrire la règle la plus étroite possible, la valider avec visudo, puis vérifier deux choses : que l’action prévue fonctionne et que ce qui n’a pas été autorisé reste refusé.

---