Chapitre 3.2 — sudo & moindre privilège

⏱️ TL;DR — Le moindre privilège est la règle d’or de l’administration : on travaille avec le minimum de droits nécessaires, et on monte en root seulement quand il le faut, ponctuellement. L’outil pour ça, c’est sudo : il exécute une seule commande en root, en te demandant ton mot de passe (pas celui de root), et journalise qui a fait quoi. On donne ce droit en ajoutant l’utilisateur au groupe sudo (Debian/Ubuntu) ou wheel (Red Hat). La configuration vit dans /etc/sudoers, qu’on n’édite jamais directement mais toujours via visudo (qui valide la syntaxe avant de sauver — une erreur ici peut te verrouiller dehors). Dernière brique : une fois sudo en place, on désactive la connexion root directe pour supprimer la cible n°1 des attaques.

🎯 Objectifs

• Comprendre et appliquer le principe de moindre privilège.
• Utiliser sudo pour une commande ponctuelle, et savoir quand sudo -i se justifie.
• Donner (ou retirer) les droits d’admin via le groupe sudo / wheel.
• Éditer la config sudo sans danger avec visudo et les fichiers /etc/sudoers.d/.
• Comprendre pourquoi et comment désactiver le login root direct.

Le moindre privilège : la règle d’or

Le principe de moindre privilège (least privilege) tient en une phrase : n’aie que les droits dont tu as besoin, au moment où tu en as besoin, et pas plus. Appliqué à un serveur, ça veut dire : tu passes ta journée en utilisateur normal (deploy), aux droits limités, et tu ne prends les pouvoirs de root que le temps d’une commande qui l’exige (installer un paquet, éditer /etc, redémarrer un service).

Pourquoi ? Parce qu’en root permanent, la moindre erreur est catastrophique et irréversible : pas de garde-fou. En utilisateur normal, une commande destructrice échoue (« permission denied ») avant de faire des dégâts — le système te protège de toi-même. Et si un script malveillant ou un process compromis s’exécute, il n’hérite que de tes maigres droits, pas de tout le système.

💡 Réflexe — Ta session par défaut ne doit jamais être root. Si ton invite de commande se termine par # (le symbole de root) au lieu de $, pose-toi la question : « ai-je vraiment besoin d’être root là, maintenant ? » La réponse est presque toujours non. Sors avec exit et reviens en utilisateur normal.

sudo : monter en root, une commande à la fois

sudo (substitute user do, ou « superuser do ») exécute une commande avec les droits de root, puis te rend la main aussitôt. La différence avec « être root » est fondamentale : tu restes toi, tu demandes juste l’élévation pour cette commande précise.

apt install nginx
# -> Permission denied : un utilisateur normal ne peut pas installer de paquet
 
sudo apt install nginx
# -> sudo demande TON mot de passe, puis exécute la commande en root.
#    La main te revient ensuite en tant qu'utilisateur normal.

Trois propriétés rendent sudo bien supérieur à une connexion root partagée :

• Il demande ton mot de passe, pas celui de root. Le mot de passe root peut même rester inconnu de tous (c’est le cas par défaut sur Ubuntu). Un secret de moins à gérer et à faire fuiter.
• Il journalise tout : chaque commande sudo est enregistrée (qui, quand, quelle commande). Sur un serveur partagé, on sait qui a fait quoi. Une connexion root anonyme, elle, ne trace rien.
• Il est granulaire : on peut autoriser un utilisateur à ne lancer que certaines commandes en root (voir plus bas), au lieu du tout-ou-rien.

🐚 Au terminal — Quelques usages fréquents de sudo :

sudo systemctl restart nginx   # redémarrer un service (droit root requis)
sudo -u postgres psql          # lancer une commande en tant qu'UN AUTRE user (ici postgres)
sudo !!                        # relancer la DERNIÈRE commande avec sudo (après un "permission denied")

sudo -i et sudo su ouvrent un shell root complet (une session interactive #). C’est parfois utile pour une série d’opérations administratives d’affilée, mais ça te ramène aux dangers de root : à n’utiliser que sciemment, jamais par confort. Préfère sudo devant chaque commande tant que c’est raisonnable — tu gardes le filet de sécurité du « permission denied ».

⚠️ Piège — Prendre le réflexe de sudo su dès la connexion « pour ne plus taper sudo ». Tu retombes exactement dans le travers qu’on veut éviter : session root permanente, aucun garde-fou, journalisation appauvrie (les commandes lancées dans le shell root ne sont plus tracées individuellement). Le confort de ne plus taper sudo ne vaut pas le risque.

Donner les droits : le groupe sudo (ou wheel)

Qui a le droit d’utiliser sudo ? Par convention, les membres d’un groupe : sudo sur Debian/Ubuntu, wheel sur Red Hat/Fedora/Rocky. Ajouter quelqu’un à ce groupe lui donne les pleins pouvoirs via sudo.

sudo adduser deploy               # créer l'utilisateur (si ce n'est pas déjà fait)
sudo usermod -aG sudo deploy      # l'ajouter au groupe sudo (Debian/Ubuntu)
# Sur Red Hat, ce serait : sudo usermod -aG wheel deploy

Après ça, deploy doit se reconnecter pour que l’appartenance au groupe prenne effet, puis il peut administrer :

# Une fois reconnecté en tant que deploy :
groups                # doit maintenant lister ... sudo
sudo apt update       # ça marche : demande le mot de passe de deploy

🔒 Sécurité — Le groupe sudo est la clé de l’administration : quiconque y figure peut devenir root. Traite l’appartenance à ce groupe comme un secret sensible. N’y mets que les comptes qui en ont réellement besoin, et retire immédiatement un compte qui n’a plus lieu d’y être (sudo deluser <user> sudo). Un audit régulier de getent group sudo (qui liste ses membres) fait partie de l’hygiène d’un serveur.

visudo : éditer sudoers sans se tirer une balle dans le pied

La configuration de sudo vit dans /etc/sudoers : quel utilisateur (ou groupe) peut lancer quelles commandes, en tant que qui, avec ou sans mot de passe. Une ligne typique :

# Les membres du groupe "sudo" peuvent tout faire (avec leur mot de passe)
%sudo   ALL=(ALL:ALL) ALL
# Le "%" désigne un GROUPE (ici sudo). Chaque champ : hôtes = (users:groups) commandes

Règle absolue : on n’ouvre JAMAIS /etc/sudoers avec un éditeur classique. On l’édite toujours avec visudo :

sudo visudo
# ouvre sudoers dans un éditeur, MAIS vérifie la syntaxe avant d'enregistrer.
# Si tu as fait une faute, il refuse de sauver et te laisse corriger.

Pourquoi cette discipline ? Parce qu’une erreur de syntaxe dans sudoers casse sudo pour tout le monde. Et comme c’est justement sudo qui te sert à réparer… tu te retrouves verrouillé dehors, sans moyen de revenir en root (à moins d’un accès console de secours chez ton hébergeur). visudo valide le fichier avant de le sauver : c’est ton filet de sécurité contre l’auto-verrouillage.

⚠️ Piège — Éditer /etc/sudoers avec nano ou vim directement « pour aller vite ». Une virgule manquante ou un mot-clé mal orthographié, tu sauves, et plus personne ne peut utiliser sudo — donc plus personne ne peut réparer sudoers. C’est l’une des façons les plus classiques de se bloquer un serveur. Toujours visudo.

Les fichiers /etc/sudoers.d/ : la bonne pratique moderne

Plutôt que de modifier le gros fichier /etc/sudoers, la pratique recommandée est de déposer des petits fichiers dans le répertoire /etc/sudoers.d/. Chacun est chargé automatiquement, ce qui garde les règles modulaires et survivant aux mises à jour du système. On les crée aussi avec visudo, via son option -f :

sudo visudo -f /etc/sudoers.d/deploy
# et on y met, par exemple :
# deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart formacampus-front

Cet exemple autorise deploy à redémarrer uniquement ce service précis, sans mot de passe — pratique pour un script de déploiement automatisé, tout en restant granulaire : deploy ne gagne aucun autre pouvoir root. C’est le moindre privilège poussé au niveau de la commande.

💡 Réflexe — NOPASSWD est puissant mais dangereux : n’accorde jamais NOPASSWD: ALL (ça revient à un root sans mot de passe). Réserve-le à des commandes précises et sûres, typiquement pour un compte de service ou de CI qui doit agir sans intervention humaine.

La journalisation : qui a fait quoi

Chaque appel sudo est enregistré par le système (sur Ubuntu/Debian, dans le journal d’authentification, consultable via journalctl ou /var/log/auth.log). Tu y vois qui a lancé quelle commande, quand, et depuis quel terminal :

sudo journalctl -e | grep sudo    # les dernières entrées sudo dans le journal
# ... deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/apt install nginx

Cette traçabilité est l’un des grands intérêts de sudo sur un serveur partagé : en cas d’incident, tu remontes aux actions d’administration. Une connexion root partagée, elle, est anonyme — impossible de savoir qui a tapé la commande fatale.

Désactiver le login root direct

Dernière brique du chapitre, et pont vers la Partie 4 : une fois que tu as un utilisateur deploy avec sudo et que tu as vérifié qu’il fonctionne, tu désactives la connexion root directe, surtout par SSH.

Pourquoi ? Parce que le compte root existe sur toutes les machines Linux : c’est la cible n°1 des attaques par force brute. Les robots tentent en permanence root + mots de passe courants. En interdisant le login root, tu supprimes cette cible : l’attaquant devrait deviner à la fois un nom d’utilisateur (qu’il ne connaît pas) et son mot de passe. Concrètement, dans /etc/ssh/sshd_config, on passe PermitRootLogin no (détaillé au Chapitre 4).

🔒 Sécurité — L’ordre des opérations est vital : (1) crée deploy, (2) donne-lui sudo, (3) teste qu’il se connecte et que sudo marche pour lui, puis seulement (4) désactive le login root. Si tu désactives root avant d’avoir un accès admin de secours fonctionnel, et que quelque chose cloche, tu es enfermé dehors. Toujours garder une session admin ouverte pendant qu’on durcit.

🧭 Sur FormaCampus — L’équipe applique la séquence à la lettre sur son VPS Ubuntu : elle crée deploy, l’ajoute au groupe sudo, ouvre une seconde session SSH avec deploy pour vérifier que tout marche (sans fermer la session root d’origine), teste un sudo apt update, puis désactive PermitRootLogin. Elle ajoute aussi un fichier /etc/sudoers.d/deploy-ci autorisant le futur pipeline de déploiement à redémarrer uniquement les services formacampus-front et formacampus-api en NOPASSWD — juste ce qu’il faut pour automatiser, rien de plus. Résultat : plus de root en direct, chaque action admin tracée, et un compte de CI au périmètre chirurgical.

✏️ Exercices

Exercice 1 — Sécurise l’accès admin. Tu viens de recevoir un VPS neuf, connecté en root. Décris (avec les commandes) les étapes pour te doter d’un accès admin sûr sans jamais te verrouiller dehors.

# En root sur le VPS neuf :
adduser deploy                 # 1. créer l'utilisateur
usermod -aG sudo deploy        # 2. lui donner sudo

Exercice 2 — Corrige le mauvais réflexe. Un collègue se connecte au serveur et tape aussitôt sudo su - pour « travailler tranquille ». Explique-lui en deux points pourquoi c’est une mauvaise habitude, et ce qu’il devrait faire à la place.

🧠 Quiz de révision

Chapitre suivant : Permissions Unix (rwx) — lire et régler qui peut lire, écrire et exécuter chaque fichier.