systemd-run0 se prépare à remplacer sudo — ce que les administrateurs Linux doivent savoir

Le 1er août 2026, Fedora 43 est sortie avec systemd 257 à bord, introduisant run0 comme alternative intégrée au vénérable sudo. Ubuntu 26.04.1, dont la sortie est prévue le 14 août 2026, devrait emboîter le pas. Lennart Poettering, auteur de systemd et de run0, a présenté cette vision comme « la fin du bit SUID en tant que mécanisme de sécurité » lors de la systemd.conf 2026 à Berlin en juin.

Aucune distribution majeure n’a encore activé run0 par défaut à la place de sudo. Fedora 43 l’intègre comme alternative — les deux commandes cohabitent. Ubuntu 26.04.1 devrait faire de même. Mais la direction est claire : le bit SUID a 46 ans, 150 000 lignes de C, et un cimetière de CVE. La communauté systemd pousse pour que run0 devienne la nouvelle norme.

Pour les administrateurs Linux qui gèrent des parcs de serveurs avec Ansible, des pipelines CI/CD qui invoquent sudo dans des conteneurs, ou des postes de travail où les développeurs ont des règles sudoers sur mesure, cette transition — même progressive — mérite d’être anticipée.

run0 vs sudo : ce qui change dans le mécanisme d’élévation

Comprendre la différence entre sudo et run0 nécessite de regarder ce qui se passe au niveau du noyau quand vous tapez sudo apt update.

sudo est un binaire SUID root. Quand vous l’exécutez, le noyau Linux change l’UID effectif du processus de votre UID utilisateur (1000) vers 0 (root). Le processus apt hérite de cet UID effectif et s’exécute avec les pleins privilèges root. Ce mécanisme fonctionne depuis quatre décennies, mais il présente trois faiblesses structurelles :

• Le processus fils hérite de l’environnement de l’appelant. Les variables d’environnement comme HOME, PATH, LD_PRELOAD et PYTHONPATH sont partiellement nettoyées par sudo (via l’option env_reset activée par défaut dans les distributions modernes), mais l’histoire de sudo est jonchée de CVE liées à des contournements de ce nettoyage — notamment CVE-2023-22809 (janvier 2023) qui permettait l’édition de fichiers arbitraires via sudoedit.

• Le binaire SUID est une surface d’attaque persistante. Le code de sudo fait environ 150 000 lignes de C. Chaque ligne est un point d’entrée potentiel pour une escalade de privilèges. CVE-2021-3156 (Baron Samedit, janvier 2021) a démontré qu’un buffer overflow dans sudo pouvait donner un shell root à un utilisateur non privilégié.

• sudo crée une session hybride. Le processus exécuté par sudo appartient au PID namespace et à la cgroup de l’utilisateur qui l’a invoqué. Il tourne sous le même systemd user manager. Si le processus est compromis, il peut interagir avec les autres processus de l’utilisateur.

run0 résout ces trois problèmes en changeant radicalement de modèle. Au lieu d’élever les privilèges du processus appelant, run0 demande à systemd (PID 1) de créer un nouveau processus dans une unité de service temporaire isolée, avec un environnement propre, dans une nouvelle cgroup et sous un nouveau user manager. L’utilisateur ne reçoit pas un shell root. Il reçoit un PTY connecté au processus isolé.

# Avec sudo : le shell s'exécute avec UID 0 dans l'environnement de l'appelant
$ sudo -i

# Avec run0 : systemd crée une unité temporaire isolée
$ run0
==== Communicating with systemd-run, drop-in sudo replacement. ====

Lennart Poettering, systemd.conf 2026

Le résultat pratique est immédiat : l’environnement est parfaitement propre. Pas de HOME=/home/user, pas de PATH hérité, pas de LD_PRELOAD. Le processus s’exécute dans une PTY entièrement nouvelle, isolé de la session utilisateur.

Ce qui casse immédiatement avec run0

Le changement de modèle signifie que certaines commandes et habitudes qui fonctionnaient avec sudo ne fonctionnent plus avec run0 — ou fonctionnent différemment. Voici les trois points de friction les plus fréquents signalés par les premiers utilisateurs de Fedora 43 :

1. Les redirections shell ne fonctionnent pas

Avec sudo, les redirections sont exécutées par le shell de l’utilisateur avant que sudo ne soit invoqué :

# Fonctionne avec sudo, ne fonctionne pas avec run0
sudo echo "nameserver 8.8.8.8" > /etc/resolv.conf
# → Permission denied : le shell utilisateur tente d'écrire dans /etc/

La solution avec run0 est d’encapsuler la commande dans un shell :

run0 sh -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'

Ce comportement n’est pas un bug — c’est précisément le résultat de l’isolation stricte entre le shell utilisateur et le shell privilégié. Le shell utilisateur n’a jamais accès aux privilèges root, donc il ne peut pas écrire dans /etc/. C’est le comportement souhaité pour la sécurité, mais il casse des décennies de mémoire musculaire.

2. Les variables d’environnement ne sont pas héritées

# Avec sudo : MYVAR est disponible dans le processus fils
export MYVAR="production"
sudo -E ./deploy.sh
# → MYVAR est transmise (si env_reset est désactivé ou avec -E)

# Avec run0 : l'environnement est toujours propre
export MYVAR="production"
run0 ./deploy.sh
# → MYVAR n'est pas définie

Pour transmettre des variables d’environnement avec run0, utilisez l’option --setenv :

run0 --setenv=MYVAR=production --setenv=DATABASE_URL=postgres://... ./deploy.sh

3. Les règles sudoers ne sont pas reprises

run0 n’utilise pas /etc/sudoers. Il utilise Polkit, le framework d’autorisation de systemd. Les règles sudoers existantes — monuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx — doivent être traduites en règles Polkit au format JavaScript :

// /etc/polkit-1/rules.d/50-nginx-restart.rules
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "nginx.service" &&
        subject.user == "monuser") {
        return polkit.Result.YES;
    }
});

Cette migration est le plus gros chantier pour les administrateurs de parcs. Les fichiers sudoers complexes, construits sur des années de politiques d’accès granulaire, doivent être réécrits pour Polkit. Fedora 43 inclut un outil de migration automatique (sudoers2polkit) qui convertit les règles simples, mais les règles avancées (Command Aliases, Cmnd_Alias, User_Alias) nécessitent une relecture manuelle.

Pourquoi systemd pousse run0 maintenant

La motivation derrière run0 n’est pas technique, elle est architecturale. Le monde Linux migre progressivement vers des systèmes où PID 1 gère l’ensemble du cycle de vie des processus. systemd contrôle le démarrage, l’arrêt, les cgroups, les namespaces, les sockets et le logging de tous les services. Le bit SUID de sudo est une exception — un reliquat d’un modèle Unix antérieur à systemd, où l’élévation de privilèges passait par un bit magique sur le système de fichiers plutôt que par une demande structurée au gestionnaire de processus du système.

run0 referme cette brèche architecturale. L’élévation de privilèges devient une opération comme une autre, gérée par systemd à travers ses mécanismes standard de création d’unités de service. Le bénéfice collatéral — la disparition d’une surface d’attaque de 150 000 lignes de C SUID — est la cerise sur le gâteau, pas la motivation première.

État des lieux par distribution

• Fedora 43 (1er août 2026) : run0 est disponible et intégré. sudo reste installé et fonctionnel. Les deux commandes cohabitent. Aucune annonce officielle de remplacement par défaut.
• Ubuntu 26.04.1 (prévu 14 août 2026) : run0 devrait être disponible. La communauté s’attend à une cohabitation sudo/run0, mais Canonical n’a pas confirmé de calendrier de migration.
• Debian 13 Trixie : run0 est disponible dans les dépôts backports mais pas activé. Le projet Debian a explicitement refusé de remplacer sudo avant d’avoir un outil de migration sudoers→polkit audité par son équipe sécurité.

Les distributions restent prudentes. Remplacer un outil de 46 ans qui fonctionne sur des millions de serveurs ne se fait pas en une release.

Plan d’anticipation pour les administrateurs

Même sans adoption obligatoire, se familiariser avec run0 dès maintenant est une bonne idée :

1. Dès maintenant : installez run0 sur une machine de test. Prenez vos 10 commandes sudo les plus fréquentes et testez-les avec run0.
2. 2026-2027 : auditez vos fichiers sudoers et identifiez les règles complexes. Testez sudoers2polkit pour mesurer le taux de conversion automatique.
3. À partir d’Ansible 11 (novembre 2025) : la directive ansible_become_method accepte déjà run0. Testez vos playbooks en parallèle.

# ansible.cfg — test run0 sur un sous-ensemble de serveurs
[privilege_escalation]
become_method = sudo  # garder sudo par défaut

# Par host (inventaire) pour un test ciblé
[test_run0]
fedora43-test.example.com ansible_become_method=run0

Verdict

run0 est techniquement supérieur à sudo, mais sudo n’est pas mort. Si vous gérez un parc homogène sous Fedora 43, testez run0 dès maintenant : l’outillage est mature, les gains de sécurité sont réels et vos développeurs s’adapteront en une semaine.

Si vous gérez un parc hétérogène mêlant Ubuntu 24.04, Debian 12 et RHEL 9, ne changez rien. sudo reste supporté et bénéficiera de correctifs de sécurité pendant encore cinq ans minimum. La pire décision serait de migrer la moitié du parc et de maintenir deux systèmes d’élévation — c’est une complexité opérationnelle que ni vos playbooks Ansible ni votre équipe de garde ne vous remercieront d’avoir introduite.

Familiarisez-vous avec run0, faites vos tests, mais gardez sudo en production jusqu’à ce qu’une distribution majeure active run0 par défaut — ce qui n’est pas encore arrivé.

Références

• systemd 257 Release Notes, GitHub, juin 2026.
• Lennart Poettering — systemd.conf 2026 keynote, media.ccc.de, juin 2026.
• Fedora 43 Release Notes, Fedora Project, 1er août 2026.
• Ubuntu 26.04.1 Release Notes, Canonical, août 2026.
• FOSS Linux — Saying Goodbye to Sudo: Mastering run0 in 2026, août 2026.
• Ansible 11 — become_method run0, documentation Ansible, novembre 2025.
• Polkit Manual — Authorization Rules, freedesktop.org.