Discussion :

[Jade Emy]

Systemd v256 présente run0 : Une alternative plus sûre à sudo, une nouvelle approche de l'élévation de privilèges sécurisée, visant à éliminer progressivement les binaires SUID traditionnels.

Lennart Poettering présente run0 dans systemd v256, une nouvelle approche de l'élévation de privilèges sécurisée, visant à éliminer progressivement les binaires SUID traditionnels.

sudo est un programme pour les systèmes d'exploitation informatiques de type Unix qui permet aux utilisateurs d'exécuter des programmes avec les privilèges de sécurité d'un autre utilisateur. Il signifiait à l'origine "superuser do" car c'était tout ce qu'il faisait, et c'est son utilisation la plus courante.

Contrairement à la commande similaire su, les utilisateurs doivent, par défaut, fournir leur propre mot de passe pour l'authentification, plutôt que le mot de passe de l'utilisateur cible. Après l'authentification, et si le fichier de configuration autorise l'accès de l'utilisateur, le système invoque la commande demandée. Le fichier de configuration propose des autorisations d'accès détaillées, notamment l'activation des commandes uniquement à partir du terminal d'invocation, l'exigence d'un mot de passe par utilisateur ou par groupe, l'exigence d'une nouvelle saisie du mot de passe à chaque fois ou l'absence totale de mot de passe pour une ligne de commande particulière.

La commande sudo est largement considérée comme un outil fondamental dans les opérations quotidiennes sous Linux, à tel point sa présence est tenue presque pour acquise. Mais suite à cette présentation, il se pourrait que ses jours soient peut-être comptés et que les nouvelles versions de systemd pourraient marquer le début de son déclin.

Dans son dernier billet, Lennart Poettering, le maître d'œuvre de systemd, présente une critique réfléchie et un remplacement robuste de la commande sudo, qui existe depuis longtemps. Selon lui, le problème principal de sudo réside dans sa nature SUID, qui permet à un processus de s'exécuter avec des privilèges élevés partiellement contrôlés par du code non privilégié, exigeant un nettoyage manuel méticuleux - une recette pour des failles de sécurité potentielles.

Je pense personnellement que le plus gros problème de sudo est le fait qu'il s'agisse d'un binaire SUID - la grande surface d'attaque, les plugins, l'accès au réseau, etc. qui viennent ensuite ne font qu'aggraver le problème principal...

À la lumière de ce qui précède, sa vision d'un système plus sûr implique l'élimination complète des binaires SUID et la mise en place d'une architecture où le code privilégié fonctionne indépendamment des interférences non privilégiées.

Dans mon monde idéal, nous aurions un système d'exploitation entièrement dépourvu de SUID. Jetons le concept de SUID sur la décharge des mauvaises idées d'UNIX. Un contexte d'exécution pour le code privilégié qui est à moitié sous le contrôle du code non privilégié et qui nécessite un nettoyage manuel minutieux n'est tout simplement pas la façon dont l'ingénierie de la sécurité devrait être faite en 2024.

Voici run0, la dernière innovation de systemd dont la sortie est prévue pour la version 256. Il ne s'agit pas seulement d'un nouvel outil, mais d'un systemd-run réimaginé, accessible via un lien symbolique, qui imite sudo sans être réellement un binaire SUID.

Il fonctionne en demandant au gestionnaire de services d'exécuter des commandes sous l'UID de l'utilisateur cible, en créant un nouveau PTY (pseudoterminal) et en transférant des données entre l'ATS d'origine et ce PTY. Cette configuration garantit que la commande s'exécute dans un environnement isolé, à partir du PID 1, sans hériter d'un contexte problématique de la part du client.

De plus, run0 évite les complexités de la configuration traditionnelle en utilisant polkit pour l'autorisation, en rationalisant les interactions avec l'utilisateur et en sécurisant davantage le processus d'exécution. L'outil ajoute également une touche de convivialité : lorsqu'il fonctionne avec des privilèges élevés, il modifie l'arrière-plan du terminal en lui donnant une teinte rougeâtre, ce qui sert de repère visuel pour indiquer le statut élevé de l'utilisateur - un rappel simple mais efficace pour gérer les privilèges de manière responsable.

En conclusion, une chose est sûre : cela suscitera de nouveaux débats au sein de la communauté Linux. Une autre certitude est que systemd v256 est maintenant achevé à 88 %, et qu'il ne reste plus grand-chose avant la sortie de la version stable finale. Reste à savoir ce qui se passera ensuite.

Source : Lennart Poettering

Et vous ?

Pensez-vous que run0 est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Les utilitaires "sudo" et "su" sont en train d'être réécrits dans le langage Rust pour assurer une meilleure sécurisation de la mémoire. L'initiative bénéficie du soutien financier d'AWS

Une vulnérabilité sur Sudo permettant aux utilisateurs non autorisés d'agir en tant que root sur Linux a récemment été corrigée dans la dernière version (1.8.28) de l'utilitaire

La version Windows de la vénérable commande Linux "sudo" devrait bientôt être disponible sous Windows 11 : Windows finira-t-il par devenir une distribution Linux classique ?

[Metal3d]

Comme pour systemd, on va avoir des réticences, il va être menacé de mort, de gens vont forker comme des sales pour faire genre qu'ils sont meilleurs. Et puis ce sera généralisé et tout le monde sera finalement content.

Parce que systemd, personnellement, je trouve ça très bien. Et run0 me paraît, sur le papier, une excellente idée.

Et j'ai généralement confiance en Lennart.

[Escapetiger]

Pour expliciter ce que Metal3d vient d'écrire ci-dessus:

Controverses

Il a été critiqué au sein de la communauté des utilisateurs pour la complexité apportée par ses systèmes, notamment PulseAudio et systemd. Ses détracteurs lui opposent le principe KISS, en vertu duquel un programme doit faire peu de choses mais les faire bien sans réinventer la roue, ce qui fait partie des principes d'un système UNIX. La polémique au sujet de systemd a été très vive et il reçut même des menaces de mort, avant un appel à l’apaisement par Linus Torvalds en personne. En réaction à l’adoption de systemd par Debian est née la distribution Devuan, en tant que fork conservant SysV init. En dépit de ceci, systemd, qui a depuis gagné en maturité, est aujourd’hui largement adopté parmi les principales distributions Linux.

Poettering quitte Red Hat discrètement courant 2022 tout en continuant à contribuer sur systemd pour rejoindre ensuite Microsoft.

Source Wikipedia: Lennart Poettering


Par ailleurs, je partage le constat fait par l'auteur à propos des failles liées aux binaires SUID issus d' UNIX.

Ce qui est inquiétant avec Lennart Poettering, c'est qu'il développe, brillamment certes, en mode boite noire, ce qui vaut, par exemple pour PulseAudio, quelques désagréments (pour rester dipomate, cf. ici).

Il est encore plus inquiétant de savoir que ce monsieur travaille maintenant pour Microsoft, on est bien là dans un conflit majeur d'intérêt, susceptible de hérisser une fois de plus la communauté Linux, quand bien même son travail est d' utilité publique.

On peut, à propos de sa personnalité, s'interroger sur le choix de son pseudo (cf @pid_eins sur Mastodon ici).
Pid Eins correspond à PID 1 en allemand, je ne sais pas si c'est de l'humour et/ou de l'égo, à vous de voir :

Identifiant de processus
« L'identifiant de processus ou PID (Process IDentifier) est un code unique attribué sur les systèmes Unix ou Windows à tout processus lors de son démarrage. Il permet ainsi d'identifier le processus dans la plupart des commandes s'appliquant sur un processus donné (comme kill).

Sous Linux le premier programme démarré, init, a le PID 1 ...
»

A suivre

[papajoker]

ce monsieur travaille maintenant pour Microsoft, on est bien là dans un conflit majeur d'intérêt

A bon ?
microsoft contribue à linux depuis plus de 10 ans !
La division azure / linux représente des milliards de revenus annuels ! Ce monsieur travaille bien pour sa société et sans aucun conflit : ils utilisent linux et gagnent énormément d'argent avec. Qu'ils y contribuent me semble un minimum !

[abriotde]

Le problème c'est qu'il veut toujours faire le truc qui fait tout qui remplace tout... Et là en gros, il veut faire passer le sudo dans SystemD. SystemD est déjà trop central, il se rends trop nécessaire pour faire tout. Vous vous demandez peut-être en quoi est-ce un problème. C'est un problème car ce n'est pas KISS (Keep It Simple and Stupid) qui est la phylosophie à la base de UNIX et une excellente philosophie informatique qui a maintes fois montré qu'elle était la meilleure. Le principe est que un programme doit rester simple et pour ça faire une seule chose et le faire bien. Alors évidemment plus l'on avance plus les choses se complexifient et c'est normal mais disons que cela doit rester le plus simple possible.
SystemD est le programme qui démarre les processus de l'ordinateur. En soit c'est un excellent processus mais il a un énorme défaut c'est qu'il veut tout contrôler et que les programmes dépendent de lui. Et ça c'est une très mauvaises choses. Un programme doit être le plus indépendant de son environnement possible pour une raison simple c'est que l'on doit pouvoir le porter ailleurs (Sur un autre Linux a minima comme un OS embarqué, et mieux sur un autre UNIX).
Oui au run0 s'il ne dépends pas de SystemD. Il faut une interface entre les 2 de manière à pouvoir le démarrer sur un OS sans systemD.
L'idée n'est pas mauvaise mais la mise en œuvre est déplorable.

[abriotde]

Parce que systemd, personnellement, je trouve ça très bien. Et run0 me paraît, sur le papier, une excellente idée.

Et j'ai généralement confiance en Lennart.

Ce n'est pas que SystemD soit une mauvaise chose, c'est son implémentation non KISS qui pause problème. Aujourd'hui tous les soft deviennent dépendant de SystemD, c'est un problème. Et en plus il le sont pour l'affichage ou pour le son... alors que SystemD est censé gérer que le démarrage (Et relance en cas de plantage).
Lennart n'est pas idiot mais buté et n'arrive pas a penser KISS ou dit autrement interopérabilité.

[Jipété]

Alors moi, j'ai remarqué un truc curieux, au démarrage de ma machine : une fois qu'elle a booté et qu'elle est up'n'running, je lance mais parfois pas tout de suite le gestionnaire de machines virtuelles et de là un vieux XP sp2 solid as a rock mais pareil, lancé un peu n'importe quand, c'est variable en fonction de mon envie de café, du temps à chauffer l'eau, etc.

Et ce que j'ai constaté à la fin du démarrage de XP, c'est que la musiquette Windows n'a jamais le même rendu : des fois c'est tout hachuré, des fois il en manque au début des fois il en manque à la fin et très très rarement c'est tout bon, bref, si le son était une image, elle serait quasiment à chaque fois toute déchirée, chiffonnée, massacrée, vraiment désagréable, et tout ça depuis la mise en prod' de ce host sous Debian up-to-date (environ 2 ans).
Avant, aucun problème avec les machines précédentes, sans SystemD...

c'est son implémentation non KISS qui pause problème.

Si ça pause problème, ce n'est pas grave ; ce qui est grave, c'est quand ça pose problème...

[Ti-Slackeux]

Avant, aucun problème avec les machines précédentes, sans SystemD...

Facile : https://www.devuan.org/

Debian sans systemd, ça devrait le faire pour vous.

Sinon il y a Slackware, sans systemd et sans dépendances ^^"

hth,

[Jipété]

Facile : https://www.devuan.org/

Debian sans systemd, ça devrait le faire pour vous.

Il me semble bien l'avoir testé dans une machine virtuelle et n'avoir pas été convaincu, pourquoi ?, je ne me souviens pas, ça remonte bien à 2 ou 3ans...

Sinon il y a Slackware, sans systemd et sans dépendances ^^"

Plus de mises à jour depuis début 2022, ça sent la fin...

Mais merci d'avoir pensé à fournir ces pistes.

[Ti-Slackeux]

Plus de mises à jour depuis début 2022, ça sent la fin...

Mais merci d'avoir pensé à fournir ces pistes.

Slackware ??????????????

Mon pauvre c'est tout faux, il suffit de regarder le changelog de la current par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Fri May  3 17:37:59 UTC 2024
a/hwdata-0.382-noarch-1.txz:  Upgraded.
a/ndctl-79-x86_64-1.txz:  Upgraded.
l/gtk4-4.14.4-x86_64-1.txz:  Upgraded.
xap/gimp-2.10.38-x86_64-1.txz:  Upgraded.
+--------------------------+
Thu May  2 23:49:58 UTC 2024
a/btrfs-progs-6.8.1-x86_64-1.txz:  Upgraded.
a/kernel-firmware-20240502_28f75f1-noarch-1.txz:  Upgraded.
a/kernel-generic-6.6.30-x86_64-1.txz:  Upgraded.
a/kernel-huge-6.6.30-x86_64-1.txz:  Upgraded.
a/kernel-modules-6.6.30-x86_64-1.txz:  Upgraded.
ap/mariadb-10.11.7-x86_64-2.txz:  Rebuilt.
       Try to preserve the timestamp on rc.mysqld.new.
d/kernel-headers-6.6.30-x86-1.txz:  Upgraded.
d/llvm-18.1.5-x86_64-1.txz:  Upgraded.
d/rust-1.78.0-x86_64-1.txz:  Upgraded.
k/kernel-source-6.6.30-noarch-1.txz:  Upgraded.
l/SDL2-2.30.3-x86_64-1.txz:  Upgraded.
n/mobile-broadband-provider-info-20240502-noarch-1.txz:  Upgraded.
x/ibus-1.5.30-x86_64-1.txz:  Upgraded.
isolinux/initrd.img:  Rebuilt.
kernels/*:  Upgraded.
usb-and-pxe-installers/usbboot.img:  Rebuilt.
+--------------------------+
Wed May  1 18:48:17 UTC 2024
ap/nano-8.0-x86_64-1.txz:  Upgraded.
ap/vim-9.1.0386-x86_64-1.txz:  Upgraded.
l/liburing-2.6-x86_64-1.txz:  Upgraded.
xap/vim-gvim-9.1.0386-x86_64-1.txz:  Upgraded.

Et pareil pour la stable ou ARm ou autre ....http://www.slackware.com/changelog/

Slackware est bien vivante, https://www.linuxquestions.org/questions/slackware-14/

Le 14 c'est du au fait que changer le nom d'un thread c'est une longue histoire, du coup 14= 15 et current.
En fait Slackware quoi ^^"

hth,

[abriotde]

Facile : https://www.devuan.org/

Debian sans systemd, ça devrait le faire pour vous.

D'accord mais le problème majeur de SystemD ce n'est pas qu'il gère le démarrage c'est que comme il fait tout, il a une grande surface d'attaque et de plus en plus de logiciels en deviennent dépendant. Devuan, remplace SystemD pour le démarrage. Mais outre le fait qu'il n'est pas forcément meilleur pour pouvoir faire tourner les logiciels dépendant de SystemD ils ont fait un logiciel qui a le rôle de SystemD avec cette même surface d'attaque.
Autrement dit, tu n'a pas systemD en lui même mais 2 soft qui réunit ont les même fonctionnalités. C'est un peu bonnet blanc et blanc bonnet (Enfin pas tout à fait mais bon).

[Ti-Slackeux]

D'accord mais le problème majeur de SystemD ce n'est pas qu'il gère le démarrage c'est que comme il fait tout, il a une grande surface d'attaque et de plus en plus de logiciels en deviennent dépendant. Devuan, remplace SystemD pour le démarrage. Mais outre le fait qu'il n'est pas forcément meilleur pour pouvoir faire tourner les logiciels dépendant de SystemD ils ont fait un logiciel qui a le rôle de SystemD avec cette même surface d'attaque.
Autrement dit, tu n'a pas systemD en lui même mais 2 soft qui réunit ont les même fonctionnalités. C'est un peu bonnet blanc et blanc bonnet (Enfin pas tout à fait mais bon).

J'ai pas tout compris
systemd, c'est un joyeux monolythe, une belle blackbox imho
Quels sont les logiciels auquel vous faites référence qui feraient le taf de systemd ?

[chrtophe]

Pour le prb de son avec l'XP virtualisé, qu'est ce qui te fait penser que c'est systemd le prob ?

[Jipété]

Mon pauvre c'est tout faux, il suffit de regarder le changelog de la current par exemple :

J'ai regardé la page principale du site et j'y ai trouvé ça :


et plus bas dans cette page un lien vers l'annonce officielle :


et un lien vers les Release Notes :


Je ne suis pas allé plus loin.

Pour le prb de son avec l'XP virtualisé, qu'est ce qui te fait penser que c'est systemd le prob ?

Parce que d'un côté je ne l'avais pas dans la machine précédente où systemD n'était pas actif, et d'un autre côté, dès l'installation de la nouvelle machine, j'ai eu des problèmes d'identification de ses disques, très certainement liés à ce principe systemD de tout démarrer en même temps, problèmes qui ont disparu quand j'ai créé un noyau dans lequel j'ai figé l'identification des disques.

Bon week-end,

[disedorgue]

Au début j'étais contre systemd pour les raisons déjà cités plus haut mais faut quand même reconnaitre que si on se donne un peu la peine de comprendre comment il fonctionne, c'est un peu plus propre que ce que l'on avait avant avec les script foireux de démarrage des services entre autre chose.

Et bizarre qu'il n'y ait pas encore eu de fork de debian par des récalcitrant sur l'utilisation de journalctl au lieu de (r)syslog

[xdelatour]

[...] ils ont fait un logiciel qui a le rôle de SystemD avec cette même surface d'attaque.
Autrement dit, tu n'a pas systemD en lui même mais 2 soft qui réunit ont les même fonctionnalités.

De quel logiciel s'agit-il ? Je compte justement passer à Devuan pour éviter systemd mais, s'ils ont créé un logiciel qui fait la même chose, cela ne présente plus aucun intérêt.

Et bizarre qu'il n'y ait pas encore eu de fork de debian par des récalcitrant sur l'utilisation de journalctl au lieu de (r)syslog

journalctl fait partie des binaires fournis avec systemd, donc ce n'est pas présent non plus sur Devuan

[chrtophe]

Qu'on aime ou pas systemd, comme il est maintenant la référence, il faut faire avec. Ne pas le faire c'est partir vers des galères.

[xdelatour]

Qu'on aime ou pas systemd, comme il est maintenant la référence, il faut faire avec.

Certes, mais c'est la référence "sous Linux" uniquement (pour l'instant vu que ça marche aussi sous WSL).

Ne pas le faire c'est partir vers des galères.

J'en suis bien conscient et c'est pour ça que je vais sans doute partir plutôt vers BSD (je teste Devuan et NetBSD sur des VM pour l'instant). J'ai pu me passer du bloatware Windows depuis les années 1990 (dès que j'ai eu mon premier PC en 1997). Je vais maintenant essayer de me passer du bloatware Linux.

Pour revenir au sujet de l'article : un simili-sudo qui ouvre un pseudo-terminal pour communiquer avec je ne sais quel service et qui utilise aussi polkit pour éviter "les complexités de la configuration traditionnelle ", je ne suis pas sûr que ce soit moins complexe ou plus sécurisé que l'existant. Quant au fait que "L'outil ajoute également une touche de convivialité" en changeant l'arrière-plan ? Le prompt différent n'était pas suffisant ? Pourtant cela s'apprenait à l'école.

Je ne veux pas dire que "c'était mieux avant", mais remplacer des choses fonctionnelles par des choses plus lourdes avec plus d'interdépendances (donc avec plus de probabilités de bug ou panne) ou à moitié finies (genre Wayland qui, lorsque X.org sera définitivement abandonné, va m'empêcher d'utiliser la télémaintenance pour le boulot parce que le rendu distant "is outside the scope of Wayland"), j'ai quand même du mal à voir où se situe le progrès.

[chrtophe]

Certes, mais c'est la référence "sous Linux" uniquement (pour l'instant vu que ça marche aussi sous WSL).

Oui mais dans la réalité des faits, on travaille sous Linux plutôt que sur un autre Unix-like.

Pour revenir au sujet de l'article : un simili-sudo qui ouvre un pseudo-terminal pour communiquer avec je ne sais quel service et qui utilise aussi polkit pour éviter "les complexités de la configuration traditionnelle ", je ne suis pas sûr que ce soit moins complexe ou plus sécurisé que l'existant.

Je ne veux pas dire que "c'était mieux avant", mais remplacer des choses fonctionnelles par des choses plus lourdes avec plus d'interdépendances

Je suis tout à fait d'accord. Si on maitrise sudo avec ses risques ça peut être plus secure qu'un système qu'on ne maitrise pas, mais il faut prendre en compte que le nouveau système devrait normalement être conçu security be design.

[papajoker]

au fait que "L'outil ajoute également une touche de convivialité" en changeant l'arrière-plan ? Le prompt différent n'était pas suffisant ? Pourtant cela s'apprenait à l'école.

Ne pas confondre su et sudo ! sudo existe pour lancer une commande donc le prompt n'est pas utilisé. Ou alors, on recommande le sudo -s dans les écoles ?
Mais, ce changement de couleur me paraît être un gadget en temps normal. Utile uniquement dans les scripts qui utilisent plusieurs fois sudo (puisque le mot de passe n'est généralement pas redemandé). Ou si je lance a la suite plusieurs scripts qui utilisent sudo en interne.