Parmi les développeurs du gestionnaire de systèmes systemd, une discussion est en cours sur la réduction des dépendances de la bibliothèque libsystemd, qui est liée non seulement aux composants de systemd, mais aussi à de nombreuses applications externes. Par exemple, dans Fedora, plus de 150 paquets utilisent libsystemd comme dépendance. L'initiateur de la discussion estime que l'inclusion de bibliothèques tierces supplémentaires dans libsystemd, qui ne sont pas contrôlées par les développeurs de systemd, augmente considérablement la surface d'attaque en cas de compromission de ces bibliothèques, comme cela a été le cas avec la bibliothèque liblzma.
En plus de liblzma et glibc, libsystemd charge également les bibliothèques libzstd, liblz4 et libgcrypt, dont le maintien de la sécurité devient une tâche critique. libsystemd fournit un accès à 12 API de base (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path et sd-resolve) créant une situation où une application, par exemple, utilisant libsystemd uniquement pour appeler la fonction sd_notify afin d'informer systemd d'un changement d'état ou sd_journal pour enregistrer des données dans le journal, se lie à toutes les autres bibliothèques et gestionnaires d'API. Pour y remédier, il est proposé de diviser libsystemd en plusieurs bibliothèques distinctes, chacune responsable d'une API spécifique, ce qui permettrait de charger des dépendances tierces uniquement lorsque cela est nécessaire.
Les développeurs de systemd estiment que cette séparation n'est pas judicieuse, car les gestionnaires présents dans libsystemd sont interconnectés. La séparation nécessiterait un travail énorme et entraînerait soit une perte d'efficacité, soit la nécessité de dupliquer du code. Pour réduire l'occupation mémoire dans libsystemd, un changement a récemment été adopté avec la mise en œuvre du chargement dynamique des bibliothèques liblzma, libzstd et liblz4 via un appel à dlopen(), dans des situations où leurs fonctions sont réellement nécessaires. Un changement similaire sera également mis en œuvre pour libgcrypt à partir de la prochaine version.
Cette décision a été critiquée car, au lieu d'un lien explicite et manifeste, le chargement des bibliothèques tierces sera désormais effectué de manière implicite, ce qui compliquera le diagnostic, car la liaison entre les appels d'API de libsystemd et les fonctions des bibliothèques externes n'est pas évidente. Le passage au chargement via dlopen() ne change pas l'architecture en soi, mais cache simplement les composants externes aux mainteneurs et aux utilisateurs.
Leonard Pottering a exprimé un désaccord catégorique avec l'idée de diviser libsystemd en plusieurs bibliothèques, car une telle étape compliquerait considérablement le partage de code dans systemd et nécessiterait de rendre tous les gestionnaires internes publics ou de les compiler statiquement dans chaque bibliothèque. Dans le premier cas, des problèmes de maintien de la stabilité de l'API et des espaces de noms surgiront, tandis que dans le second, cela augmenterait la taille en raison de la duplication du code.
La stratégie mise en place pour le prochain lancement de chargement des bibliothèques externes uniquement si nécessaire est perçue par Leonard comme une stratégie optimale. Le problème de la complexité d'obtention des données sur les bibliothèques chargées de manière dynamique est proposé d'être résolu par l'ajout de champs supplémentaires dans les fichiers ELF contenant des informations sur ces dépendances dynamiques, qui peuvent être traitées par les débogueurs et affichées dans la sortie de l'outil readelf.
En ce qui concerne le lien entre libsystemd et de nombreuses applications, Leonard a recommandé aux développeurs d'applications de ne pas essayer de charger libsystemd pour une seule fonction, mais de mettre en œuvre le gestionnaire de protocole au niveau de l'application. Par exemple, l'implémentation de la fonctionnalité sd_notify() est suffisamment triviale et peut se faire en quelques lignes de code en utilisant des sockets UNIX (AF_UNIX). Une telle réalisation isolée de sd_notify est disponible pour OpenSSH depuis 2017 et a récemment été acceptée dans la branche portable d'OpenSSH 9.8, dont la sortie est prévue pour le milieu de l'été.
Source : opennet.ru
