
A systemd rendszeradminisztrációs démonok halmaza
Nemrég a a systemd fejlesztői megbeszélést folytattak amelyben az asztalra került a libsystemd könyvtári függőségek csökkentésének kérdése (a szolgáltatások megvalósításáért és a systemd-vel való interakcióért felelős könyvtár). Ez azért van, mert jelenleg van egy bizonyos aggodalomra ad okot a libsystemdben a harmadik féltől való függőség növekedése miatt, amelyeket a projekt nem vezérel és ez növeli a támadási felületet. A vitaindító megjegyzi, hogy a libsystemd a liblzma és a glibc mellett számos kritikus könyvtárat is betölt, mint például a libzstd, liblz4 és libgcrypt. Ez jelentős biztonsági problémákat vet fel, különösen, ha ezek a harmadik féltől származó könyvtárak feltörtek.
A Fedorán például több mint 150 csomag függ a libsystemd-től, ami növeli a bonyolultságot és a kapcsolódó kockázatokat. A javaslatot Ennek kezelése magában foglalja felosztja a libsystemd-t több különálló könyvtárra, amelyek mindegyike egy adott API-ért felel. Ez lehetővé tenné, hogy a harmadik féltől származó függőségeket csak szükség esetén töltsék be, ezáltal csökkentve a rendszerfejlesztők által közvetlenül nem ellenőrzött könyvtárak potenciális sebezhetőségét.
Azonban, fejlesztők által systemd Azzal érvelnek, hogy ez az elválasztás problémás lenne a libsystemd-ben található illesztőprogramok összekapcsolása miatt. Úgy vélik, hogy a felosztás munkaigényes lenne, és a hatékonyság elvesztéséhez vagy a kód megkettőzésének szükségességéhez vezethet, ami ellensúlyozná a tervezett biztonsági előnyöket.
A teljes szétválás helyett A libsystemd egy dinamikusabb megközelítést választott a dinamikus betöltéssel szükség esetén a liblzma, libzstd és liblz4 könyvtárakat a dlopen() hívás használatával. A tervek szerint a jövőbeli kiadásokban hasonló változtatást hajtanak végre a libgcrypt esetében, hogy mind a biztonsági aggályokat, mind a kódhatékonysági és karbantarthatósági igényeket kielégítsék.
Úgy gondolom, hogy ezeknek a függőségeknek a többségére nincs szükség az olyan alapvető libsystemd függvények megvalósításához, mint amilyenek a fent említettek.
Ez a probléma azt jelentheti, hogy a libsystemd több különböző API-t megvalósító könyvtárra oszlik fel, amelyek közül az egyik, például a libsystemd-core, csak a libc-től függ, míg más speciálisabb könyvtárak további függőségeket adnak hozzá. Továbbá, ha a függőségek egy része csak bizonyos rendszerszolgáltatásokhoz szükséges, helyezze át a függőségeket ezekre a szolgáltatásokra.
Ennek végeredménye a támadási felület csökkentése és a rendszerbiztonság javítása.
A vita során Volt egy pont, amelyet a fejlesztők többsége kritizált, és megemlítik, hogy a harmadik fél könyvtárainak implicit betöltésére vonatkozó döntés a dlopen() használatával a libsystemdben további munkát generálna a diagnosztika bonyolultsága és a hivatkozások láthatóságának hiánya miatt azt is megemlítik, hogy ez bonyolítja a külső könyvtári funkciókhoz kapcsolódó libsystemd API-hívások azonosítását, mivel ez nem nyilvánvaló a kódban. Ez az új betöltési mód, bár nem változtatja meg az alapul szolgáló architektúrát, elrejti a külső összetevőket a karbantartók és a felhasználók elől.
Lenart Pottering nem ért egyet azzal az ötlettel, hogy a libsystemd-et több könyvtárra osztják fel a bonyolultságok miatt, ami a kódmegosztást és az API és névtér stabilitásának fenntartását eredményezné. A libsystemd felosztása az összes belső illesztőprogram feltárását vagy statikus fordítását igényelné minden egyes könyvtárban, ami megnövelheti a méretet a kódduplikáció miatt, vagy megnehezítheti a rendszer stabilitásának és konzisztenciájának kezelését.
Megosztás helyett a külső könyvtárak csak szükség esetén történő betöltésének stratégiája optimálisnak tekinthető, Ezen túlmenően a diagnosztika bonyolultabbá tétele érdekében további mezők hozzáadása az ELF-fájlokhoz a betöltött dinamikus függőségekre vonatkozó információkkal, lehetővé téve a hibakeresők számára, hogy feldolgozzák ezeket az információkat, és megjelenítsék azokat az olyan eszközök kimenetén, mint a readelf. Ez nagyobb átláthatóságot és áttekinthetőséget biztosítana a libsystemd által használt dinamikus függőségekben, így könnyebbé válik a dinamikusan betöltött külső könyvtárakkal kapcsolatos problémák diagnosztizálása és hibakeresése.
Lenart ajánlotta a fejlesztőknek olyan alkalmazások közül, ahelyett, hogy közvetlenül a libsystemd-hez kapcsolnánk egy adott funkcióhoz, az alkalmazás szintjén egy protokollkezelő van megvalósítva.
Ez a protokoll-illesztőprogramok alkalmazásszintű megvalósításának stratégiája számos előnyt kínáls:
- Csökkenti a libsystemd-től való függőséget, és elkerüli a külső könyvtárak betöltését, amikor nincs rájuk szükség.
- Nagyobb rugalmasságot és irányítást biztosít az alkalmazás által megkívánt specifikus funkciók felett.
- Leegyszerűsíti a diagnózist és a hibakeresést azáltal, hogy közvetlenebb ellenőrzést biztosít bizonyos funkciók megvalósítása felett.
- Általánosságban elmondható, hogy ez a megközelítés elősegíti az alkalmazások modularását és függetlenségét, javítva a rugalmasságot és a hatékonyságot a szoftverfejlesztés és -karbantartás terén.
Ha érdekelne többet megtudni róla, ellenőrizheti a részleteket A következő linken.