Évolution de sudo : de su d'Unix aux privilèges modernes

Voici un fait qui surprend la plupart des gens : quand vous tapez votre mot de passe dans sudo, vous ne voyez absolument aucun retour. Pas d'astérisques, pas de points, rien. Le curseur reste immobile. Ce choix de conception date des années 1980 et déroute les utilisateurs depuis plus de quatre décennies. Beaucoup pensent que leur terminal a planté, tapent leur mot de passe plusieurs fois ou supposent que quelque chose ne fonctionne pas. Ubuntu a enfin décidé d'afficher des astérisques par défaut, mettant fin à 46 ans de saisie silencieuse.

Ce petit changement en dit long : la manière dont Linux gère l'élévation de privilèges est un assemblage de décisions prises au fil des décennies, certaines brillantes, d'autres franchement discutables, et toutes marquées par la nécessité de rester compatibles avec l'existant. Comprendre comment on en est arrivé là vous aide à prendre de meilleures décisions de sécurité aujourd'hui.

Avant sudo : le monde de su

Le tout premier outil d'élévation de privilèges sous Unix était su, pour « substitute user ». Il ne faisait qu'une chose : basculer toute votre session shell vers un autre utilisateur, généralement root. Vous tapiez su, saisissiez le mot de passe de root, effectuiez votre travail d'administration, puis reveniez à votre compte habituel.

$ su
Password: [type root's password]
# whoami
root
# apt install nginx
# exit
$ whoami
normaluser

Les limites de su sont vite devenues évidentes à mesure que les systèmes Unix dépassaient une poignée d'opérateurs de confiance. Tous ceux qui avaient besoin d'un accès admin devaient connaître le mot de passe de root. Quand quelqu'un quittait l'équipe, il fallait changer ce mot de passe et le redistribuer à tout le monde. Il n'y avait aucune piste d'audit : une fois devenu root, chaque utilisateur apparaissait comme « root » dans les journaux, sans qu'on sache qui avait fait quoi. Et su donnait un shell root complet, si bien qu'une simple faute de frappe pouvait détruire le système.

L'histoire classique qui fait froid dans le dos : un admin voulait taper rm -rf /tmp/old_files, mais a appuyé sur Entrée après avoir tapé rm -rf /. Avec un shell root complet, rien n'empêche la commande de s'exécuter. su ne faisait aucune distinction entre « cette personne doit redémarrer nginx » et « cette personne a besoin d'un accès illimité à tout le système ».

Comment sudo a réglé le problème du mot de passe root

sudo (« superuser do ») a été créé en 1980 à SUNY Buffalo par Bob Coggeshall et Cliff Spencer. L'idée centrale était simple mais transformatrice : plutôt que de partager le mot de passe root, permettre à chaque utilisateur d'exécuter des commandes précises en tant que root avec son propre mot de passe. L'administrateur contrôle qui peut lancer quoi via un fichier de configuration.

Cela a résolu plusieurs problèmes d'un coup :

• Pas de mot de passe root partagé. Chaque utilisateur s'authentifie avec ses propres identifiants. Quand quelqu'un part, il suffit de retirer son accès sudo. Aucune rotation de mot de passe nécessaire.
• Permissions granulaires. Vous pouvez autoriser un développeur à redémarrer un service précis sans lui donner un accès root complet.
• Piste d'audit. Chaque commande sudo est journalisée avec le nom de l'utilisateur, la commande exécutée et l'heure.
• Élévation temporaire. Au lieu d'un shell root ouvert, sudo exécute une seule commande avec des privilèges élevés, puis redescend au niveau normal.

# Run a single command as root
$ sudo apt install nginx
[sudo] password for priya:
# That's YOUR password, not root's
# The audit trail in /var/log/auth.log:
# Mar 20 14:23:01 web-03 sudo: priya : TTY=pts/0 ;
#   PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/apt install nginx

Le fichier sudoers : puissant et dangereux

La configuration de sudo se trouve dans /etc/sudoers, et sa syntaxe est vraiment l'une des choses les plus déroutantes de l'administration Linux. Une seule erreur de syntaxe peut vous couper complètement l'accès à sudo, c'est pourquoi la commande visudo existe : elle valide le fichier avant de l'enregistrer.

# /etc/sudoers syntax:
# WHO  WHERE = (AS_WHOM) WHAT
# Let priya run anything as root on any host
priya ALL=(ALL:ALL) ALL
# Let the 'webdev' group restart nginx only
%webdev ALL=(root) /usr/bin/systemctl restart nginx,\
/usr/bin/systemctl reload nginx
# Let deploy user run deploys without a password
deploy ALL=(root) NOPASSWD: /opt/deploy/run.sh
# DANGEROUS: This looks restrictive but isn't
bob ALL=(root) /usr/bin/vim
# Bob can now run: sudo vim, then :!bash to get a root shell

Ce dernier exemple, qui donne accès à vim via sudo, est un piège de sécurité dans lequel on tombe constamment. Vim (et bien d'autres programmes) peut lancer des commandes shell. Si un utilisateur peut faire sudo vim, il dispose en pratique d'un accès root illimité. C'est pareil avec less, man, awk, find, python et des dizaines d'autres commandes. Le projet GTFOBins tient une liste complète des binaires permettant de s'échapper d'un shell restreint.

Les bizarreries et pièges de sécurité de sudo

sudo a accumulé des comportements vraiment étranges au cours de ses plus de 40 ans d'histoire. Comprendre ces particularités est essentiel pour la sécurité :

• Cache des identifiants. Une fois votre mot de passe saisi, sudo le garde en cache pendant 15 minutes par défaut. Pendant ce laps de temps, toute commande sudo s'exécute sans authentification. Si vous quittez un terminal déverrouillé, n'importe qui peut lancer des commandes sudo pendant jusqu'à 15 minutes. Exécutez sudo -k pour vider immédiatement le cache.
• Le paramètre tty_tickets. Par défaut, le cache de sudo est propre à chaque terminal. Mais sur certains systèmes, s'authentifier dans un terminal déverrouille sudo dans tous les autres. Vérifiez vos réglages Defaults.
• Variables d'environnement. sudo nettoie la plupart des variables d'environnement, mais pas toutes. LD_PRELOAD et LD_LIBRARY_PATH sont supprimées, mais si env_keep est mal configuré, un attaquant peut injecter des chemins de bibliothèques malveillants. C'est à la base de plusieurs exploits réels d'élévation de privilèges.
• Le piège de NOPASSWD. NOPASSWD est pratique pour l'automatisation, mais dangereux s'il est appliqué trop largement. Une application compromise tournant sous un utilisateur disposant de NOPASSWD est en pratique root, sans mot de passe à casser.

# Security hardening for sudoers:
# Require password every time (disable caching)
Defaults timestamp_timeout=0
# Or reduce cache to 1 minute
Defaults timestamp_timeout=1
# Ensure credential cache is per-terminal
Defaults tty_tickets
# Log all sudo I/O (records full terminal sessions)
Defaults log_input, log_output
Defaults iolog_dir=/var/log/sudo-io
# Require root password instead of user password
# (prevents compromised user accounts from sudo-ing)
Defaults rootpw
# Show asterisks when typing password
Defaults pwfeedback

Alternatives modernes : doas, polkit et run0

La complexité de sudo a donné naissance à plusieurs alternatives, chacune adoptant une philosophie différente.

doas : sudo sans la complexité

doas d'OpenBSD (« dedicated OpenBSD application subexecutor ») a été créé par Ted Unangst en 2015, précisément parce que sudo était devenu trop complexe pour être audité. La configuration tient généralement en 2 ou 3 lignes :

# /etc/doas.conf — the entire configuration
permit persist priya
permit nopass deploy as root cmd /opt/deploy/run.sh
# That's it. Compare this to a typical sudoers file.
# 'persist' is like sudo's credential caching
# 'nopass' is like NOPASSWD

Le code source de doas fait environ 2 500 lignes de C. Celui de sudo dépasse les 150 000. Pour les systèmes où vous n'avez pas besoin des fonctions avancées de sudo (comme la correspondance d'arguments par commande ou l'intégration LDAP), doas est nettement plus simple à configurer, à auditer et à sécuriser. Je l'utilise sur mes serveurs personnels depuis des années, et je ne regrette pas sudo une seconde.

polkit : privilèges de bureau à grain fin

PolicyKit (polkit) suit une approche complètement différente. Au lieu d'encapsuler des commandes individuelles, il définit des actions que les applications peuvent demander. Quand une application de bureau doit modifier les paramètres réseau, elle demande l'autorisation à polkit, qui décide selon ses règles de l'accorder, de la refuser ou de demander confirmation à l'utilisateur.

C'est ainsi que votre bureau Linux vous permet de monter une clé USB sans mot de passe, tout en exigeant une authentification pour installer un logiciel. La granularité se situe au niveau de l'action et non de la commande, ce qui correspond mieux à la façon dont les utilisateurs de bureau pensent réellement les permissions.

run0 : la refonte radicale de systemd

run0 de systemd est le petit nouveau, et son fonctionnement diffère fondamentalement de celui de sudo. Au lieu d'exécuter une commande en root depuis votre session existante (ce qui nécessite des bits setuid et crée de sérieux maux de tête de sécurité), run0 demande au gestionnaire de services de lancer un nouveau service tournant en root. Votre session utilisateur n'obtient jamais de privilèges élevés : le processus privilégié est totalement séparé.

Cette approche supprime des familles entières de vulnérabilités sudo : pas de binaire setuid, pas de cache d'identifiants, pas de surface d'injection de variables d'environnement. Le compromis est qu'il nécessite systemd, ce qui le rend inadapté aux systèmes BSD et aux installations Linux minimalistes. Mais pour les serveurs basés sur systemd, c'est sans doute l'option la plus sûre disponible.

Recommandations pratiques

Après des années à administrer des serveurs Linux et à enquêter sur des incidents d'élévation de privilèges, voici ce que je recommande concrètement :

1. Désactivez complètement la connexion root. Utilisez sudo ou doas pour tout. Il ne devrait exister aucun mot de passe root partagé.
2. Utilisez des groupes plutôt que des utilisateurs individuels dans sudoers. Gérez les accès par appartenance à un groupe. Quand quelqu'un part, retirez-le du groupe.
3. Ne donnez jamais sudo à des interpréteurs ou à des éditeurs. Pas de sudo vim, sudo python ni sudo less. Pour modifier un fichier appartenant à root, utilisez plutôt sudoedit.
4. Limitez les règles NOPASSWD. Réservez-les aux processus automatisés, et uniquement pour des commandes précises données avec leur chemin complet.
5. Activez la journalisation de sudo. Au minimum, journalisez toutes les commandes sudo. Pour les systèmes sensibles, activez la journalisation complète des entrées-sorties.
6. Envisagez doas pour les systèmes plus simples. Si vous n'avez pas besoin de l'intégration LDAP ni de règles de correspondance complexes, doas est plus facile à maîtriser.
7. Réduisez agressivement la durée du cache des identifiants. Ramenez timestamp_timeout à 1-5 minutes, ou désactivez complètement le cache sur les serveurs de production.

Le meilleur mécanisme d'élévation de privilèges est celui qui accorde le minimum d'accès nécessaire, pendant le minimum de temps nécessaire, avec une piste d'audit complète. Tout le reste est un compromis.

sudo ne disparaîtra pas. Il est bien trop ancré dans les scripts, l'automatisation, la documentation et les réflexes des administrateurs. Mais le paysage des alternatives n'a jamais été aussi riche. Que vous restiez sur sudo (correctement durci), que vous passiez à doas (pour la simplicité) ou que vous adoptiez run0 (pour les systèmes critiques), l'essentiel est de comprendre ce que fait réellement votre outil d'élévation de privilèges. Car l'écart entre ce que l'on croit que sudo fait et ce qu'il fait vraiment est précisément là où se cachent la plupart des incidents de sécurité.