A systemd-ben felvetődik a libsystemd függőségek csökkentésének ötlete

systemd

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.


Hagyja megjegyzését

E-mail címed nem kerül nyilvánosságra. Kötelező mezők vannak jelölve *

*

*

  1. Az adatokért felelős: AB Internet Networks 2008 SL
  2. Az adatok célja: A SPAM ellenőrzése, a megjegyzések kezelése.
  3. Legitimáció: Az Ön beleegyezése
  4. Az adatok közlése: Az adatokat csak jogi kötelezettség alapján továbbítjuk harmadik felekkel.
  5. Adattárolás: Az Occentus Networks (EU) által üzemeltetett adatbázis
  6. Jogok: Bármikor korlátozhatja, helyreállíthatja és törölheti adatait.