Root or not root

La question: qui a le droit d’être root sur un serveur partagé? La réponse n’est pas technique, elle est politique. Mais les outils techniques existent et ils ne se valent pas.

su

su demande le mot de passe root. Celui qui le connaît devient root. Point. Tous les admins partagent le même mot de passe et quand quelqu’un part de l’équipe, il faut le changer (et le redistribuer). L’historique de ce qui a été fait en root se limite à last et à la mémoire de ceux qui étaient là.

sudo

sudo demande le mot de passe de l’UTILISATEUR (pas celui du root) et exécute la commande spécifiée dans /etc/sudoers. L’avantage: chaque action en root passe par le log de sudo (/var/log/auth.log), chaque utilisateur garde son propre mot de passe et le fichier sudoers contrôle QUI peut faire QUOI.

# /etc/sudoers
%admin ALL=(ALL) ALL           # le groupe admin peut tout faire
user1 ALL=(root) /etc/init.d/apache2 restart   # user1 peut restart Apache
user2 ALL=(root) NOPASSWD: /usr/bin/apt-get    # user2 peut apt-get sans password

La ligne NOPASSWD est le genre de chose qui fait gagner du temps et perdre la sécurité en même temps: si le compte user2 est compromis, l’attaquant a apt-get en root, ce qui veut dire installer un package arbitraire, ce qui veut dire root complet. Le NOPASSWD a un coût et il faut le connaître.

Le fichier sudoers

Le fichier se modifie avec visudo, jamais avec vim direct (visudo vérifie la syntaxe avant de sauver, un sudoers cassé = plus de sudo du tout). La syntaxe:

qui      où=(comme qui)      quoi
user     ALL=(root)          /usr/bin/passwd
%group   ALL=(ALL)           ALL

Ce que je fais

Sur mes serveurs, PermitRootLogin no dans sshd_config, le root n’est jamais accessible en SSH direct. Les admins passent par leur compte et sudo su - (ou sudo -i). Le sudoers limite les commandes aux opérations nécessaires et les logs de sudo traquent ce qui a été fait, par qui, quand.

La commande sudo su - donne un shell root complet, ce qui contourne la granularité du sudoers. Mais elle est loggée (l’entrée dans le shell root est tracée) et après c’est la responsabilité de l’admin. Le sudoers limite l’entrée, pas le comportement une fois entré.

[edit: 2026] Le modèle de sudo décrit dans cet article a été démoli entre-temps. Pas par une faille, par une prise de conscience: GTFOBins (gtfobins.github.io ) a catalogué que presque TOUT binaire présent sur un système Linux peut être utilisé pour escalader vers un shell root quand il est lancé via sudo.

Le NOPASSWD que je recommandais dans cet article:

user2 ALL=(root) NOPASSWD: /usr/bin/apt-get

n’est pas une limitation, c’est un root complet déguisé. apt-get exécute des hooks pre/post en root. Un package custom, un fichier de config malveillant et user2 a le root sans passer par su. Le même raisonnement s’applique à:

sudo vim fichier    → :!/bin/sh        → shell root
sudo find . -exec /bin/sh \;           → shell root
sudo less fichier   → !/bin/sh         → shell root
sudo awk 'BEGIN{system("/bin/sh")}'    → shell root
sudo python -c 'import os;os.system("/bin/sh")'  → shell root
sudo nmap --interactive                → !sh → shell root
sudo systemctl edit service            → éditer un unit file = root

La liste est encyclopédique. Le GTFOBins documente chaque binaire, chaque escape, chaque one-liner. La conclusion est brutale: la granularité du sudoers est de la théâtre tant que les binaires autorisés sont dans la liste GTFOBins. Un sudo /usr/bin/passwd user peut sembler safe: passwd appelle des helpers en root et certains d’entre eux peuvent être exploités.

Les contre-mesures modernes:

sudoedit au lieu de sudo <editeur>: sudoedit copie le fichier, lance l’éditeur sans privilège, copie en retour. L’éditeur ne tourne pas en root, donc pas d’escape shell;
Le tag NOEXEC: user2 ALL=(root) NOEXEC: /usr/bin/command empêche le binaire de fork/exec un sous-process (mais il y a des contournements);
Des scripts wrapper qui font exactement l’action nécessaire, au lieu de donner accès à l’outil générique;
sudo -l comme audit: chaque utilisateur peut lister ce qu’il peut faire en root. La sortie est la surface d’attaque et elle se compare à la liste GTFOBins;
La faille CVE-2021-3156 (Baron Samedit): une heap overflow dans l’analyse des arguments de sudo, exploitable par n’importe quel utilisateur local, sans avoir besoin d’être dans le sudoers. CVE-2019-14287: sudo -u#-1 contourne le user check. Le sudo lui-même est une surface d’attaque, pas seulement ce qu’il permet de faire.

La morale de 2026: le sudoers limite ce que le sudoers peut limiter. GTFOBins a prouvé que ce que le sudoers peut limiter est presque rien, tant que l’utilisateur a accès à un interpréteur. La vraie sécurité n’est pas dans le sudoers, elle est dans l’isolation (containers sans sudo, chroot, namespaces) et dans la séparation des privilèges par processus.