Bland systemmanagerutvecklare pÄgÄr en diskussion om att minska beroendena i libsystemd-biblioteket, som kopplas ihop inte bara med systemd-komponenter utan ocksÄ med mÄnga externa applikationer. Till exempel anvÀnder över 150 paket i Fedora libsystemd som beroende. Diskussionens initiativtagare anser att införandet av ytterligare externa bibliotek i libsystemd, som inte kontrolleras av systemd-utvecklarna, vÀsentligt ökar attackytan vid en eventuell kompromettering av externa bibliotek, som skett med liblzma-biblioteket.
Utöver liblzma och glibc laddar libsystemd Àven biblioteken libzstd, liblz4 och libgcrypt, dÀr sÀkerhetsunderhÄllet blir en kritiskt viktig uppgift. Libsystemd ger tillgÄng till 12 grundlÀggande API:er (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path och sd-resolve), och en situation uppstÄr dÀr en applikation, till exempel som anvÀnder libsystemd bara för att anropa funktionen sd_notify för att informera systemd om ett tillstÄndsÀndring eller sd_journal för att skriva data till loggen, kopplas till alla andra bibliotek och API-hanterare. Som en lösning föreslÄs att dela upp libsystemd i flera separata bibliotek, som ansvarar för specifika API:er, vilket skulle möjliggöra att extern beroende endast laddas in dÀr de verkligen behövs.
Systemd-utvecklarna anser att uppdelning Àr orealistisk, eftersom de befintliga hanterarna i libsystemd Àr ömsesidigt kopplade. Uppdelningen skulle krÀva enormt arbete och leda till antingen förlust av effektivitet eller behov av kodduplicering. För att minska minnesanvÀndningen har libsystemd nyligen genomgÄtt en förÀndring med implementeringen av dynamisk inlÀsning av bibliotek som liblzma, libzstd och liblz4 genom att anvÀnda anropet dlopen(), i situationer dÀr deras funktioner verkligen Àr nödvÀndiga. En liknande förÀndring kommer att genomföras för libgcrypt frÄn och med nÀsta version.
SĂ„dana lösningar har kritiserats, eftersom istĂ€llet för tydlig och mĂ€rkbar koppling, kommer inlĂ€sningen av externa bibliotek nu att ske otydligt, vilket komplicerar diagnosen, eftersom kopplingen mellan API-anropen i libsystemd och anrop av funktioner frĂ„n externa bibliotek inte Ă€r uppenbar. ĂvergĂ„ngen till inlĂ€sning genom dlopen() förĂ€ndrar inte arkitekturen, utan döljer bara externa komponenter för deras underhĂ„llare och anvĂ€ndare.
Lenart Pottinger uttryckte starkt missnöje med idén att dela upp libsystemd i flera bibliotek, eftersom ett sÄdant steg skulle göra gemensam anvÀndning av kod i systemd betydligt mer komplicerat och krÀva att alla interna handelskodare antingen görs offentliga eller kompileras statiskt i varje bibliotek. I det första fallet uppstÄr problem med att upprÀtthÄlla stabiliteten i API:et och namnomrÄdena, och i det andra fallet ökar storleken pÄ grund av kodduplication.
Den implementerade avlastningen av externa bibliotek endast vid behov ses av Lenart som en optimal strategi. Problemet med att komplicera Ätkomsten till data om dynamiskt laddade bibliotek föreslÄs lösas genom att lÀgga till ytterligare fÀlt med information om sÄdana dynamiska beroenden i ELF-filer, som kan behandlas av felhanterare och visas i utdata frÄn verktyget readelf.
NÀr det gÀller bindningen av ett stort antal applikationer till libsystemd rekommenderade Lenart applikationsutvecklare att inte försöka ladda libsystemd för en enda funktion, utan att implementera protokollhanteraren pÄ applikationsnivÄ. Till exempel Àr implementeringen av funktionen sd_notify() tillrÀckligt trivial och kan rymmas pÄ nÄgra rader kod vid anvÀndning av UNIX-sockets (AF_UNIX). En sÄdan separat implementation av sd_notify har varit tillgÀnglig för OpenSSH sedan 2017 och har nyligen blivit antagen i den bÀrbara grenen av OpenSSH 9.8, vars release Àr planerad till mitten av sommaren.
KĂ€lla: opennet.ru
