Mezi vývojáři systémového správce systemd probíhá diskuse o redukci závislostí knihovny libsystemd, která je propojena nejen s komponentami systemd, ale také s mnoha externími aplikacemi. Například ve Fedoře používá více než 150 balíčků libsystemd jako závislost. Iniciátor diskuse tvrdí, že zahrnutí dalších externích knihoven do libsystemd, které nejsou pod kontrolou vývojářů systemd, významně zvyšuje plochu útoku v případě kompromitace těchto externích knihoven, jak se to stalo s knihovnou liblzma.
Kromě liblzma a glibc se do libsystemd načítají také knihovny libzstd, liblz4 a libgcrypt, jejichž zabezpečení se stává kriticky důležitým úkolem. V libsystemd je k dispozici 12 základních API (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path a sd-resolve) a nastává situace, kdy aplikace, například ta, která používá libsystemd pouze pro zavolání funkce sd_notify k informování systemd o změně stavu nebo sd_journal pro zápis dat do logu, je propojena se všemi ostatními knihovnami a zpracovatelskými API. Jako řešení se navrhuje rozdělení libsystemd na několik samostatných knihoven, které by měly na starosti jednotlivá API, což by umožnilo načítat externí závislosti pouze tam, kde jsou skutečně potřebné.
Vývojáři systemd považují rozdělení za nepraktické, protože zpracovatelé přítomní v libsystemd jsou vzájemně propojeni. Rozdělení by vyžadovalo obrovské úsilí a vedlo by buď ke ztrátě efektivity, nebo k potřeba duplikace kódu. Pro snížení spotřeby paměti v libsystemd bylo nedávno přijato změnu s realizací dynamického načítání knihoven liblzma, libzstd a liblz4 prostřednictvím volání dlopen(), když jsou jejich funkce skutečně potřebné. Podobná změna bude od příštího vydání zavedena i pro libgcrypt.
Toto řešení se stalo objektem kritiky, protože místo explicitního a zřetelného propojení bude nyní načítání externích knihoven prováděno neexplicitně, což zkomplikuje diagnostiku, protože nebude zřejmá vazba mezi API voláními libsystemd a voláním funkcí z externích knihoven. Samotný přechod na načítání prostřednictvím dlopen() nemění architekturu, pouze skrývá externí komponenty před správci a uživateli.
Lenart Pöttering jasně vyjádřil nesouhlas s myšlenkou rozdělení libsystemd na několik knihoven, protože takový krok by zásadně zkomplikoval sdílení kódu v systemd a vyžadoval by převést všechny vnitřní zpracovatele do veřejné sféry nebo je staticky zkompilovat do každé knihovny. V prvním případě by mohly nastat problémy s udržováním stability API a prostorů jmen, a ve druhém by došlo ke zvýšení velikosti kvůli duplicitě kódu.
Realizované pro následující vydání načítání externích knihoven pouze na vyžádání je Lenartem vnímáno jako optimální strategie. Problém s komplikovaným získáváním dat o dynamicky načítaných knihovnách se navrhuje vyřešit přidáním dodatečných polí s informacemi o těchto dynamických závislostech do souborů ELF, které mohou být zpracovány ladicími nástroji a zobrazovány ve výstupu utilit readelf.
Pokud jde o propojení velkého počtu aplikací s libsystemd, Lenart doporučil vývojářům aplikací nepokoušet se načítat libsystemd pouze kvůli jedné funkci, ale realizovat zpracovatele protokolu na úrovni aplikace. Například implementace funkčnosti sd_notify() je dost triviální a může se vejít do několika řádků kódu při použití UNIXových soketů (AF_UNIX). Taková samostatná implementace sd_notify je od roku 2017 dostupná pro OpenSSH a nedávno byla přijata do přenosné verze OpenSSH 9.8, jejíž vydání je plánováno na polovinu léta.
Zdroj: opennet.ru
