Wśród twórców menedżera systemowego systemd toczy się dyskusja na temat zmniejszenia zależności w bibliotece libsystemd, która jest powiązana nie tylko z komponentami systemd, ale także z wieloma zewnętrznymi aplikacjami. Na przykład w Fedory ponad 150 pakietów wykorzystuje libsystemd w swoich zależnościach. Inicjator dyskusji uważa, że włączenie dodatkowych zewnętrznych bibliotek do libsystemd, które nie są kontrolowane przez deweloperów systemd, znacznie zwiększa powierzchnię ataku w przypadku kompromitacji tych zewnętrznych bibliotek, tak jak miało to miejsce z biblioteką liblzma.
Oprócz liblzma i glibc w libsystemd ładują się również biblioteki libzstd, liblz4 i libgcrypt, a zapewnienie ich bezpieczeństwa staje się kluczowym zadaniem. W libsystemd udostępniono dostęp do 12 podstawowych API (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path i sd-resolve) i istnieje sytuacja, w której aplikacja, na przykład, korzystająca z libsystemd tylko w celu wywołania funkcji sd_notify w celu poinformowania systemd o zmianie stanu lub sd_journal w celu zapisania danych w logu, łączy się ze wszystkimi innymi bibliotekami i obsługami API. Proponuje się podział libsystemd na kilka oddzielnych bibliotek, odpowiedzialnych za poszczególne API, co pozwoli na załadowanie zewnętrznych zależności tylko tam, gdzie są naprawdę potrzebne.
Deweloperzy systemd uważają, że podział nie jest celowy, ponieważ występujące w libsystemd obsługi są ze sobą powiązane. Podział wymagałby ogromnej pracy i prowadziłby albo do utraty wydajności, albo do konieczności duplikacji kodu. W celu zmniejszenia zajmowanej pamięci w libsystemd niedawno wprowadzono zmianę z realizacją dynamicznego ładowania bibliotek liblzma, libzstd i liblz4 za pomocą wywołania dlopen(), w sytuacjach, gdy ich funkcje są rzeczywiście potrzebne. Podobna zmiana od następnej wersji zostanie wprowadzona również dla libgcrypt.
Takie rozwiązanie stało się obiektem krytyki, ponieważ zamiast jawnego i wyraźnego powiązania, ładowanie zewnętrznych bibliotek będzie odbywać się teraz niejawnie, co utrudni diagnostykę, ponieważ związek wywołań API libsystemd z wywołaniami funkcji z zewnętrznych bibliotek nie będzie oczywisty. Sam przejście na ładowanie za pomocą dlopen() nie zmienia architektury, a jedynie ukrywa zewnętrzne komponenty przed utrzymującymi i użytkownikami.
Lenart Pöttering wyraził kategoryczny sprzeciw wobec pomysłu podziału libsystemd na kilka bibliotek, ponieważ krok ten znacznie skomplikuje współdzielenie kodu w systemd i będzie wymagał przetłumaczenia wszystkich wewnętrznych przetworników na publiczne lub osobnego statycznego skompilowania ich w każdą bibliotekę. W pierwszym przypadku pojawią się problemy z utrzymaniem stabilności API i przestrzeni nazw, a w drugim — wzrost rozmiaru z powodu dublowania kodu.
Zaimplementowane w następnej wersji ładowanie zewnętrznych bibliotek tylko w razie potrzeby jest postrzegane przez Lenarta jako optymalna strategia. Problem z komplikacjami przy pozyskiwaniu danych o dynamicznie ładowanych bibliotekach proponuje się rozwiązać poprzez dodanie do plików ELF dodatkowych pól z informacjami o takich dynamicznych zależnościach, które mogą być przetwarzane przez debugery i pokazywane w wynikach narzędzia readelf.
Jeśli chodzi o powiązanie z libsystemd dużej liczby aplikacji, Lenart zalecił twórcom aplikacji, aby nie próbowali ładować libsystemd tylko w celu jednej funkcji, a zamiast tego zrealizowali przetwornik protokołu na poziomie aplikacji. Na przykład, implementacja funkcjonalności sd_notify() jest wystarczająco trywialna i może zmieścić się w kilku linijkach kodu przy użyciu gniazd UNIX (AF_UNIX). Tego rodzaju odosobniona implementacja sd_notify od 2017 roku jest dostępna dla OpenSSH i niedawno została przyjęta do przenośnej gałęzi OpenSSH 9.8, której wydanie planowane jest na połowę lata.
Źródło: opennet.ru
