sudo-rs sur Ubuntu : quels changements dans sudoers ?

Ce que sudo-rs change sur Ubuntu

Ubuntu 26.04 LTS fournit sudo-rs comme sudo par défaut. Ainsi, sur un serveur fraîchement installé, la commande sudo exécute la réimplémentation en Rust au lieu du programme C d’origine. La plupart des fichiers sudoers continuent de fonctionner exactement comme avant. La règle qui ne fonctionne plus est celle qui contient un caractère générique dans les arguments d’une commande, car sudo-rs ne fait pas correspondre les motifs glob au texte des arguments.

Ubuntu 25.10 a effectué ce changement en premier, et Ubuntu 26.04 LTS l’a conservé. Ubuntu 24.04 LTS n’est pas concerné, car il utilise toujours le sudo d’origine, sauf si vous installez sudo-rs manuellement. Cela devient important lorsque vous mettez à niveau Ubuntu 24.04 vers 26.04, ou lorsque vous déployez un nouveau serveur avec la version plus récente. Si vous utilisez également les versions intermédiaires, la différence entre les versions LTS et intermédiaires d’Ubuntu sur un serveur explique quelle machine rencontre ce changement en premier.

Vérifiez quelle implémentation de sudo votre serveur exécute réellement

Ne le déduisez pas du numéro de version. Interrogez la machine.

sudo --version
update-alternatives --config sudo
dpkg -l 'sudo*'

Faites davantage confiance à sudo --version sur votre propre serveur qu’à n’importe quel tableau de versions disponible sur Internet, y compris cette page. update-alternatives --config sudo est l’autre moitié de la réponse : il liste tous les fournisseurs installés de /usr/bin/sudo et indique celui qui est sélectionné. Un paquet installé n’est pas nécessairement sélectionné. Consultez donc la sélection, pas la liste des paquets.

Les deux implémentations sont empaquetées pendant la transition. Celle écrite en Rust est sudo-rs, en version 0.2.13 dans 26.04 en août 2026. L’implémentation d’origine, maintenue par Todd C. Miller, est toujours le paquet sudo. La différence est que ses programmes portent un suffixe .ws, afin que les deux implémentations puissent être installées simultanément : /usr/bin/sudo.ws et /usr/bin/visudo.ws, ainsi que cvtsudoers.ws et sudoreplay.ws. Vérifié dans l’archive 26.04 en septembre 2026 : dpkg -L sudo liste les binaires avec suffixe, et sudo-rs fournit /usr/bin/sudo-rs à leurs côtés.

Pourquoi Ubuntu est passé à sudo-rs

sudo est setuid root. N’importe quel utilisateur de la machine peut le lancer, et il démarre avec tous les privilèges. Un bug mémoire dans ce programme peut donc permettre une élévation de privilèges locale. La CVE-2021-3156 en est un exemple exact : un dépassement de tampon du tas était exploitable par n’importe quel utilisateur local et se trouvait dans une version publiée depuis environ dix ans. Rust détecte cette catégorie de bugs lors de la compilation. C’est la raison principale de la réécriture.

La deuxième raison concerne le périmètre. C’est celle qui a une incidence sur votre configuration. Le sudo d’origine a accumulé un grand nombre de fonctionnalités en trois décennies. Chaque fonctionnalité ajoute du code exécuté avec les privilèges de root. sudo-rs n’implémente volontairement qu’un sous-ensemble de ces fonctionnalités. Ses auteurs ont écarté les éléments qu’ils jugeaient spécialisés ou activement nuisibles. Une construction sudoers qui fonctionnait depuis des années peut donc être tout simplement absente. Votre règle avec caractère générique en fait partie.

La sécurité mémoire élimine une catégorie de bugs. Elle ne rend pas un programme exempt de bugs. sudo-rs a lui aussi reçu ses propres correctifs de sécurité depuis qu’il est devenu la version par défaut. Appliquez-lui les correctifs comme à n’importe quel autre logiciel.

Quelles règles sudoers restent compatibles

Le fichier reste le même. sudo-rs lit /etc/sudoers ainsi que les fichiers drop-in de /etc/sudoers.d/, et les règles courantes écrites par les administrateurs système sont prises en charge :

• deploy ALL=(ALL:ALL) ALL, ainsi que les formes pour les groupes telles que %sudo ALL=(ALL:ALL) ALL
• les tags NOPASSWD: et PASSWD:
• User_Alias, Runas_Alias, Host_Alias et Cmnd_Alias
• une commande avec une liste exacte d’arguments, par exemple /usr/bin/systemctl restart app-api
• une commande suivie de "", qui autorise la commande uniquement sans aucun argument
• une commande suivie de * comme dernier argument, qui autorise tous les arguments supplémentaires
• un chemin de répertoire se terminant par /, qui autorise toute commande dans ce répertoire
• ! pour retirer une commande d’une liste
• un sous-ensemble utile de Defaults, notamment secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw et use_pty

Deux paramètres par défaut se comportent différemment et peuvent surprendre. env_reset ne peut pas être désactivé dans sudo-rs : il est toujours activé. use_pty est activé par défaut ; la commande s’exécute donc dans son propre pseudo-terminal.

Pourquoi votre règle sudoers avec caractère générique ne correspond plus

Les caractères génériques restent autorisés à un seul endroit : le nom de fichier de la commande. Une règle de %ops ALL = /sbin/fsck* autorise toujours sudo fsck et sudo fsck_exfat, car le * fait partie du chemin comparé au système de fichiers.

Dans la liste des arguments, sudo-rs n’accepte que deux formes spéciales, et aucune n’est un motif. "" signifie qu’il n’y a aucun argument. Un * final signifie que des arguments supplémentaires sont autorisés. Tous les autres arguments sont comparés comme du texte littéral. Ainsi, %ops ALL = /sbin/service ntp * est valide, car ntp est littéral et le * est le dernier élément. En revanche, une règle comme celle-ci n’accorde aucun accès utile :

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart app-*

app-* est un motif placé au milieu d’un argument. sudo-rs ne le développe pas. La règle ne couvre donc pas systemctl restart app-api et sudo refuse la commande. Deux commandes vous indiquent la réalité de toute règle présente sur votre serveur : sudo -l -U deploy, exécutée en tant que root, affiche ce que ce compte peut réellement exécuter, et sudo visudo -c indique si le fichier est syntaxiquement valide. Exécutez-les avant de commencer à modifier la configuration au hasard.

La règle générique comportait toujours une faille

Avec sudo d’origine, les arguments que vous saisissez sont réunis en une seule chaîne, puis comparés à la chaîne d’arguments de la règle à l’aide d’un glob. Un glob correspond aux espaces. C’est ce que presque tout le monde oublie.

La documentation de sudo-rs fournit la démonstration la plus claire. Une règle de /bin/rm *.txt autorise également sudo rm -rf /home .txt, car l’unique * absorbe -rf /home et la chaîne obtenue se termine toujours par .txt. La règle signifie « uniquement des fichiers texte ». En réalité, elle signifie « n’importe quels arguments, tant que la ligne se termine par .txt ».

Il en va de même pour l’exemple avec systemctl. Comme les arguments sont comparés sous la forme d’une seule chaîne, un motif final correspond également à tout ce que vous ajoutez après lui. Ainsi, restart app-* couvre restart app-api ainsi que tous les arguments supplémentaires ajoutés par l’appelant. Un motif placé dans un argument expose les arguments qui l’entourent, alors que les arguments déterminent les capacités d’une commande. sudo-rs refuse cette construction au lieu d’essayer de la sécuriser, car il n’existe pas de forme générale sûre de cette syntaxe.

Remplacez le caractère générique par une liste explicite de commandes

La plupart des règles avec caractère générique existent parce que quelqu’un ne voulait pas saisir quatre lignes. Saisissez les quatre lignes.

Cmnd_Alias APP_RESTART = /usr/bin/systemctl restart app-api, /usr/bin/systemctl restart app-worker
Cmnd_Alias APP_STATUS = /usr/bin/systemctl status app-api, /usr/bin/systemctl status app-worker
deploy ALL=(root) NOPASSWD: APP_RESTART, APP_STATUS

Indiquez le bon chemin. Une règle qui référence /bin/systemctl sur un système où le binaire se trouve dans /usr/bin/systemctl ne correspond jamais. L’échec ressemble alors exactement à un problème de permissions. Vérifiez avec command -v systemctl et collez le résultat affiché.

Placez la règle dans son propre fichier drop-in plutôt que dans /etc/sudoers. Ainsi, une mise à niveau du paquet ne risque pas d’écraser votre modification :

sudo visudo -f /etc/sudoers.d/90-deploy
sudo visudo -c
sudo -l -U deploy

Nommez le fichier sans point et sans tilde final. La version d’origine de sudo ignore les fichiers de sudoers.d dont le nom contient un point. 90-deploy.conf ne produit donc aucune modification visible, ce qui est un cas classique. Respecter cette convention ne coûte rien.

Utilisez un wrapper appartenant à root lorsque la liste devient longue

Lorsque l’ensemble des commandes autorisées est trop volumineux pour être listé, déplacez la décision hors de sudoers et confiez-la à un petit programme appartenant à root.

sudo tee /usr/local/sbin/app-restart >/dev/null <<'EOF'
#!/bin/sh
set -eu
case "${1:-}" in
  app-api|app-worker) ;;
  *) echo "app-restart: not allowed: ${1:-}" >&2; exit 1 ;;
esac
exec /usr/bin/systemctl restart "$1"
EOF
sudo chown root:root /usr/local/sbin/app-restart
sudo chmod 0755 /usr/local/sbin/app-restart
ls -l /usr/local/sbin/app-restart

Dans sudoers, il suffit alors d’indiquer une seule commande :

deploy ALL=(root) NOPASSWD: /usr/local/sbin/app-restart *

Le * final est acceptable ici, car c’est le script, et non sudo, qui détermine ce qui est autorisé. Cela reste vrai uniquement si le script appartient à root et n’est inscriptible par aucun autre compte. Si deploy peut écrire dans le fichier, deploy peut remplacer son contenu et exécuter n’importe quelle commande en tant que root, ce qui est pire que la règle avec joker que vous avez supprimée. Vérifiez le mode avec ls -l. Si sa sortie ne vous paraît pas évidente, lire la chaîne d’autorisations drwxr-xr-x s’apprend en cinq minutes. La même règle s’applique au répertoire : /usr/local/sbin ne doit pas non plus être inscriptible par le compte, car un répertoire inscriptible permet de remplacer entièrement le fichier.

Donnez au job son propre compte plutôt qu’une règle sudo

La meilleure question est souvent de savoir pourquoi la commande a besoin de root. Un service qui s’exécute avec son propre utilisateur peut être géré par cet utilisateur, sans aucune ligne sudoers. Pour les unités système, systemd délègue déjà cette décision à polkit. Une règle peut donc désigner une unité et un opérateur :

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "app-api.service" &&
        subject.user == "deploy") {
        return polkit.Result.YES;
    }
});

Enregistrez cette règle sous /etc/polkit-1/rules.d/50-app-api.rules. deploy peut alors exécuter systemctl restart app-api sans sudo. Testez-la depuis le contexte exact qui l’utilisera. Une règle qui fonctionne dans votre session SSH doit aussi être vérifiée depuis cron avant que vous ne comptiez dessus. Dans tous les cas, le compte qui exécute le job doit être réservé à cette tâche. C’est le même principe que celui des comptes utilisateur à privilèges minimaux sur un VPS.

Ce que sudo-rs ne prend pas en charge

sudo -E n’est pas implémenté. Définissez les variables dont vous avez besoin avec Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". N’oubliez pas que env_reset est toujours activé : tout ce qui n’est pas conservé est supprimé.

Le stockage central de sudoers dans LDAP a disparu. sudoers.ldap et cvtsudoers ne sont pas implémentés, et le paquet sudo-ldap a été supprimé dans 26.04. L’authentification LDAP via PAM ou SSSD fonctionne toujours. C’est la gestion des règles dans un annuaire qui n’est pas prise en charge.

INTERCEPT, qui tentait d’empêcher les échappements vers un shell depuis une commande autorisée, n’est pas implémenté. Cette protection ne résistait de toute façon pas à un utilisateur déterminé. Si une règle autorise quelqu’un à exécuter un éditeur ou un interpréteur en tant que root, cette personne dispose des privilèges root. Aucune option de sudo ne change cela.

L’enregistrement des sessions n’est pas implémenté. Il n’existe donc ni journal d’E/S ni sudoreplay. La journalisation utilise uniquement syslog. Aucune option logfile ne permet de la rediriger ailleurs. Les messages de sudo sont donc envoyés à l’emplacement où votre système envoie déjà les messages syslog.

Faut-il repasser à sudo.ws ?

Vous le pouvez. Pendant le cycle 26.04, le paquet d’origine reste disponible précisément pour cette raison.

sudo apt install sudo
update-alternatives --config sudo
sudo update-alternatives --set sudo /usr/bin/sudo.ws

Copiez les chemins exacts depuis la sortie de --config plutôt que depuis cette page, car cette liste correspond aux chemins acceptés par votre propre système. Pour repasser ensuite à sudo-rs, définissez l’alternative sur le chemin du binaire sudo-rs indiqué dans cette même liste.

Gardez une deuxième session SSH ouverte, connectée et inactive, avant de modifier quoi que ce soit qui concerne sudo. Un fichier sudoers impossible à analyser ou une alternative qui pointe vers un binaire non installé peut vous empêcher de devenir root sur une machine distante. Cette précaution s’ajoute aux autres tâches à effectuer pendant les dix premières minutes sur un nouveau VPS.

Considérez le retour en arrière comme une échéance, et non comme une correction. Il vous laisse une semaine pour réécrire correctement les règles. Cette réécriture reste utile en elle-même, car chaque règle utilisant un caractère générique que vous supprimez accordait davantage de droits que son auteur ne l’avait compris.

FAQ

Pourquoi ma règle wildcard dans sudoers ne fonctionne-t-elle plus sur Ubuntu 26.04 ?

Parce qu’Ubuntu 26.04 LTS utilise sudo-rs comme sudo par défaut, et que sudo-rs ne fait pas correspondre les motifs wildcard à l’intérieur des arguments d’une commande. Il autorise un wildcard dans le nom de fichier de la commande, "" pour indiquer l’absence d’arguments, ainsi qu’un seul * comme dernier argument. Une règle telle que /usr/bin/systemctl restart app-* place un motif au milieu d’un argument. Elle n’accorde donc aucun droit et la commande est refusée. Exécutez sudo -l -U deploy en tant que root pour voir les droits réellement associés au compte, puis remplacez la règle par les commandes exactes ou par un wrapper script appartenant à root.

Comment revenir au sudo d’origine sur Ubuntu 26.04 ?

Le sudo d’origine est fourni par le paquet sudo, dont les binaires portent le suffixe .ws. Installez-le avec sudo apt install sudo, puis sélectionnez-le comme alternative avec sudo update-alternatives --set sudo /usr/bin/sudo.ws. Exécutez d’abord update-alternatives --config sudo pour afficher les chemins exacts proposés par votre système, et gardez une seconde session SSH ouverte pendant la modification. Cela ne rétablit pas sudo-ldap, qui a été supprimé d’Ubuntu 26.04 quelle que soit l’implémentation sélectionnée.

sudo-rs lit-il le même fichier /etc/sudoers ?

Oui. sudo-rs lit /etc/sudoers ainsi que les fichiers drop-in situés sous /etc/sudoers.d/, avec la même syntaxe pour les utilisateurs, les groupes, les alias, les spécifications run-as et le tag NOPASSWD. Il implémente un sous-ensemble du langage sudoers. Les différences se manifestent donc par des constructions absentes, et non par des constructions dont le comportement serait différent. Modifiez le fichier avec sudo visudo, puis vérifiez-le avec sudo visudo -c avant de fermer votre session.

Que remplace sudo -E dans sudo-rs ?

sudo -E n’est pas implémenté. Il était déjà déconseillé avec le sudo d’origine, car transmettre à un processus root un environnement contrôlé par l’appelant permet couramment de modifier le comportement de ce processus. Déclarez plutôt dans sudoers les variables dont vous avez réellement besoin, avec une ligne telle que Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". env_reset est toujours activé dans sudo-rs et ne peut pas être désactivé. Toutes les variables que vous ne conservez pas sont donc supprimées.