Par contre, l'impact potentiel d'une faille est-il plus élevé si > elle touche le cœur de systemd, vue l'ampleur de ses
prérogatives?
D'un point de vue purement surface d'attaque, je pense qu'il faut déjà définir de quoi on parle. Je pense que quand les gens disent "systemd", c'est le binaire principal ( /usr/lib/systemd/systemd ).
Donc si on doit évaluer les risques, il peut écouter sur le reseau, ce qui est mal, mais il ne fait aucun traitement , ce qui diminue fortement les risques ( le plus gros souci d'un service "network facing", c'est le traitement des données externes ). Le code critique est vraiment court, et à ce niveau, il fait la même chose qu'openssh ( qui tourne aussi en root ), il recoit le socket, et il forke.
le pid 1 tourne en root, ce qui est aussi en sa défaveur, mais pas pire que iodine ou d'autres serveurs qui tourne en root. Le fait d'être pid 1 donne pas de droit spéciaux à ce niveau la dans un systéme unix, mais ça lui donne le droit de faire des transitions selinux. Ce qui est requis de part sa nature, et inévitable. Ensuite, comme beaucoup de gens ne l'utilisent pas, je pense que ça change pas grand chose à ce niveau.
Et toujours pour comparer avec openssh, openssh a aussi le droit de faire des transitions selinux un peu libre, vu qu'on peut se connecter avec sur n'importe quel uid.
Ensuite, on peut dire qu'il y a du traitement fait par systemd, mais en local. C'est vrai, ça réponds à des requêtes dbus et ce genre de choses, et je ne sais pas exactement par ou passe les données pour les logs. Donc je pense que ça reste limité en terme de traitement (parsing), ce qui diminue les risques d'autant, de part l'utilisation de choses plus haut niveau.
Donc au final, le risque est le même que celui d'une faille dans un serveur ssh, modulo le fait que systemd ne fait pas un traitement d'un protocole.
Le plus gros facteur de risque lié à openssh, c'est pas sa nature, c'est que son omniprésence, et c'est pareil dans le cas de systemd. Les années ont montrés que la monoculture ne semble pas déranger grand monde pour les serveurs ssh ( car franchement, qui tourne avec dropbear en dehors de l'embarqué, qui a entendu parler de lsh, qui s'est dit "pourquoi j'utiliserais pas mina sur mon serveur de prod" ), et qu'au final, tout le monde est d'accord pour dire "oui, faudrait faire un truc" mais n'applique pas en pratique. Et je pense que ça va être pareil pour systemd.
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
D'un point de vue purement surface d'attaque, je pense qu'il faut déjà définir de quoi on parle. Je pense que quand les gens disent "systemd", c'est le binaire principal ( /usr/lib/systemd/systemd ).
Donc si on doit évaluer les risques, il peut écouter sur le reseau, ce qui est mal, mais il ne fait aucun traitement , ce qui diminue fortement les risques ( le plus gros souci d'un service "network facing", c'est le traitement des données externes ). Le code critique est vraiment court, et à ce niveau, il fait la même chose qu'openssh ( qui tourne aussi en root ), il recoit le socket, et il forke.
le pid 1 tourne en root, ce qui est aussi en sa défaveur, mais pas pire que iodine ou d'autres serveurs qui tourne en root. Le fait d'être pid 1 donne pas de droit spéciaux à ce niveau la dans un systéme unix, mais ça lui donne le droit de faire des transitions selinux. Ce qui est requis de part sa nature, et inévitable. Ensuite, comme beaucoup de gens ne l'utilisent pas, je pense que ça change pas grand chose à ce niveau.
Et toujours pour comparer avec openssh, openssh a aussi le droit de faire des transitions selinux un peu libre, vu qu'on peut se connecter avec sur n'importe quel uid.
Ensuite, on peut dire qu'il y a du traitement fait par systemd, mais en local. C'est vrai, ça réponds à des requêtes dbus et ce genre de choses, et je ne sais pas exactement par ou passe les données pour les logs. Donc je pense que ça reste limité en terme de traitement (parsing), ce qui diminue les risques d'autant, de part l'utilisation de choses plus haut niveau.
Donc au final, le risque est le même que celui d'une faille dans un serveur ssh, modulo le fait que systemd ne fait pas un traitement d'un protocole.
Le plus gros facteur de risque lié à openssh, c'est pas sa nature, c'est que son omniprésence, et c'est pareil dans le cas de systemd. Les années ont montrés que la monoculture ne semble pas déranger grand monde pour les serveurs ssh ( car franchement, qui tourne avec dropbear en dehors de l'embarqué, qui a entendu parler de lsh, qui s'est dit "pourquoi j'utiliserais pas mina sur mon serveur de prod" ), et qu'au final, tout le monde est d'accord pour dire "oui, faudrait faire un truc" mais n'applique pas en pratique. Et je pense que ça va être pareil pour systemd.