Run0 - annonce d’un outil basé sur systemd pour remplacer sudo

run0 : l’outil de remplacement de sudo dans systemd

• Nouvel outil inclus dans la v256 (en réalité, il s’agit d’un lien symbolique vers l’existant systemd-run)
• Fonctionne de manière similaire à sudo, mais n’est pas SUID
• Demande au gestionnaire de services d’invoquer une commande ou un shell avec l’UID de l’utilisateur cible
  • Invoque la commande cible dans un contexte d’exécution isolé, nouvellement forké depuis PID 1, sans hériter du contexte côté client
• run0 n’implémente pas son propre langage de configuration et utilise polkit pour l’autorisation
• Pendant l’élévation de privilèges, l’arrière-plan du terminal prend une teinte rouge pour indiquer qu’il fonctionne avec des privilèges. Un point rouge dans le titre de la fenêtre signale également l’élévation de privilèges
• Prend en charge l’option --property= de systemd-run, ce qui permet de définir les paramètres de service souhaités pour la commande/session privilégiée invoquée

Les problèmes de sudo

• sudo est un binaire SUID relativement volumineux, c’est-à-dire du code privilégié qu’un utilisateur non privilégié peut invoquer depuis son propre contexte
• Sa surface d’attaque est importante à cause d’un langage de configuration complexe, de plugins chargeables (LDAP, etc.) et du filtrage par nom d’hôte
• Le principal problème est précisément son statut de binaire SUID. Il est invoqué par du code non privilégié et hérite d’un contexte d’exécution contrôlé par ce code non privilégié (variables d’environnement, propriétés d’ordonnancement des processus, affectation de cgroup, contexte de sécurité, descripteurs de fichiers transmis, etc.). Un binaire SUID doit nettoyer cela avec énormément de précautions, ce qui est souvent mal fait

Divers

• Avec run0, il est possible d’exécuter non seulement un shell, mais aussi d’autres commandes avec les privilèges root. À la fin du programme, la couleur du terminal revient à son état d’origine
• Le changement automatique de couleur de fond peut être gênant, mais il peut être modifié ou désactivé avec l’option --background=
• Il semble possible de remplacer complètement sudo par run0, mais les préférences peuvent varier selon les distributions
• Le modèle à plugins de sudo, notamment pour la prise en charge de LDAP, pose de nombreux problèmes. polkit peut être étendu d’une manière gérée de façon sûre dans systemd
• Le fait qu’un script bash soit exécuté via run0 peut être vérifié grâce aux variables d’environnement SUDO_xxx, compatibles avec sudo

L’avis de GN⁺

• Il est frappant que run0 soit présenté comme une alternative à sudo, très largement utilisé. Il semble conserver les avantages de sudo tout en évitant les risques liés à SUID
• Le fait d’indiquer visuellement de façon claire qu’une élévation de privilèges est en cours devrait aider à réduire les dégâts dus aux erreurs. Changer la couleur de fond du terminal peut être agaçant, mais comme cela reste configurable, cela ne semble pas être un gros problème
• La configuration des autorisations via polkit est peut-être moins flexible qu’avec sudo, mais cela peut justement simplifier l’ensemble et réduire la surface d’attaque. Une bonne documentation avec des exemples de configuration polkit paraît importante
• Pour la migration des scripts existants qui dépendent de sudo, il semble qu’il faudra encore fournir sudo pendant un certain temps. Mais dans un nouvel environnement, il serait préférable d’utiliser run0 dès le départ
• À plus long terme, on peut espérer que l’adoption de run0 serve de déclencheur pour supprimer plus franchement SUID et évoluer vers une architecture où les privilèges système sont gérés de manière centralisée par les services système. Cela paraît aller dans le bon sens en matière de sécurité et de robustesse

[GN⁺]

Avis Hacker News

• Contrairement à sudo, run0 n’hérite d’aucun contexte du client et invoque la commande cible dans un contexte d’exécution isolé, fraîchement forké depuis le PID 1. Cela ne correspond pas aux cas d’usage habituels des commandes shell, ce qui risque en pratique de causer des problèmes et de freiner son adoption à grande échelle.
• Si run0 était largement utilisé, un drapeau pour se comporter comme sudo serait ajouté, et les gens finiraient par toujours utiliser ce drapeau. Quand cela posera problème, le projet systemd pourrait alors essayer de supprimer sudo.
• run0 adopte une approche différente de sudo en établissant une frontière IPC stricte entre les niveaux de privilège. Cela peut être une bonne méthode pour les personnes qui veulent utiliser systemd.
• sudo est en grande partie maintenu par une seule personne.
• Le fonctionnement de run0 se rapproche à bien des égards davantage de ssh que de sudo. On pourrait implémenter un outil similaire en se connectant en SSH à localhost.
• Une idée similaire a été testée au milieu des années 1980 dans un clone BSD expérimental de Berkeley, mais elle a été rejetée à cause de la complexité liée au fait de tout faire transiter par des pipes. À la place, les vérifications de l’environnement hérité ont été renforcées.
• Il existe des interrogations sur run0 concernant la journalisation, les variables d’environnement transmises, la gestion des signaux et une solution de remplacement à sudoedit.
• En plus de run0, il existe aussi une implémentation de sudo écrite en Rust, sûre du point de vue mémoire et avec moins de bugs.
• De nos jours, il n’y a souvent qu’un seul utilisateur par machine physique, ce qui implique qu’il faudrait simplifier le système de permissions Unix.
• Le fait de passer l’arrière-plan du terminal en rouge lors d’une élévation de privilèges n’est pas un élément important.