systemd yra sistemos administravimo demonų rinkinys
Neseniai, sistemos kūrėjai diskutavo kurioje buvo padėta ant stalo libsystemd bibliotekos priklausomybių mažinimo problema (biblioteka, atsakinga už paslaugų diegimą ir bendravimą su sistema). Taip yra todėl, kad šiuo metu yra tam tikras susirūpinimas dėl didėjančios trečiųjų šalių priklausomybės sistemoje libsystemd, kurios nekontroliuoja projektas ir tai padidina atakos paviršių. Diskusijos pradininkas pažymi, kad libsystemd, be liblzma ir glibc, įkelia keletą svarbių bibliotekų, tokių kaip libzstd, liblz4 ir libgcrypt. Dėl to kyla didelių saugumo problemų, ypač jei šios trečiųjų šalių bibliotekos yra pažeistos.
Pavyzdžiui, „Fedora“ daugiau nei 150 paketų priklauso nuo „libsystemd“, o tai padidina sudėtingumą ir susijusią riziką. Pasiūlymas Norėdami tai išspręsti, reikia padalinti libsystemd į kelias atskiras bibliotekas, kurių kiekviena atsakinga už tam tikrą API. Tai leistų trečiųjų šalių priklausomybes įkelti tik prireikus, taip sumažinant potencialių pažeidžiamumą bibliotekose, kurių tiesiogiai nekontroliuoja sistemos kūrėjai.
Tačiau kūrėjai pagal systemd Jie teigia, kad toks atskyrimas būtų problemiškas dėl tvarkyklių, esančių libsystemd, sujungimo. Jie mano, kad padalijimas pareikalautų daug darbo ir gali sumažėti efektyvumas arba būtinybė dubliuoti kodą, o tai prieštarautų numatomai saugumo naudai.
Vietoj visiško atsiskyrimo, libsystemd pasirinko dinamiškesnį metodą dinamiškai įkeldama bibliotekas liblzma, libzstd ir liblz4, kai reikia, naudodami iškvietimą dlopen(). Panašų pakeitimą planuojama įdiegti libgcrypt būsimose versijose, kad būtų atsižvelgta į saugumo ir kodo efektyvumo bei priežiūros poreikius.
Manau, kad dauguma šių priklausomybių nėra būtinos norint įgyvendinti pagrindines libsystemd funkcijas, tokias kaip aukščiau paminėtos.
Ši problema gali reikšti libsystemd padalijimą į kelias bibliotekas, kurios įgyvendina skirtingas API, iš kurių viena, pavyzdžiui, libsystemd-core, priklausytų tik nuo libc, o kitos labiau specializuotos bibliotekos pridėtų kitų priklausomybių. Be to, jei kai kurios priklausomybės reikalingos tik tam tikroms sisteminėms paslaugoms, perkelkite priklausomybes į tas paslaugas.
Galutinis to rezultatas turėtų būti atakos paviršiaus sumažinimas ir sistemos saugumo gerinimas.
Diskusijos metu Buvo vienas punktas, kurį dauguma kūrėjų kritikavo, ir jie mini, kad sprendimas netiesiogiai įkelti trečiųjų šalių bibliotekas naudojant dlopen() programoje libsystemd sukurtų papildomo darbo dėl papildomo sudėtingumo diagnozuojant ir nuorodų matomumo stokos jie taip pat mini, kad tai apsunkina libsystemd API iškvietimų, jungiančių prie išorinių bibliotekos funkcijų, identifikavimą, nes tai nėra akivaizdu kode. Šis naujas įkėlimo būdas, nors ir nekeičia pagrindinės architektūros, slepia išorinius komponentus nuo prižiūrėtojų ir vartotojų.
Lenartas Potteringas išreiškė savo nesutikimą su idėja padalyti libsystemd į kelias bibliotekas dėl komplikacijų, tai sukeltų kodo dalijimąsi ir išlaikytų API bei vardų erdvės stabilumą. Išskaidžius libsystemd reikėtų atskleisti visas vidines tvarkykles arba statiškai jas kompiliuoti atskirai kiekvienoje bibliotekoje, o tai gali padidinti dydį dėl kodo dubliavimo arba apsunkinti sistemos stabilumo ir nuoseklumo valdymą.
Vietoj padalijimo, Strategija įkelti išorines bibliotekas tik tada, kai būtina, laikoma optimalia, Be to, siekiant išspręsti papildomą diagnostikos sudėtingumą, siūloma į ELF failus įtraukti papildomus laukus su informacija apie įkeltas dinamines priklausomybes, kad derintojai galėtų apdoroti šią informaciją ir rodyti ją įrankių, pvz., readelf, išvestyje. Tai suteiktų daugiau skaidrumo ir matomumo apie dinamines priklausomybes, naudojamas libsystemd, todėl būtų lengviau diagnozuoti ir derinti problemas, susijusias su dinamiškai įkeliamomis išorinėmis bibliotekomis.
Lenartas rekomendavo kūrėjams programų, kurios, užuot tiesiogiai susieję su libsystemd konkrečiai funkcijai, protokolų tvarkytuvas yra įdiegtas programos lygiu.
Ši protokolo tvarkyklių diegimo programos lygiu strategija siūlo keletą privalumųs:
- Sumažina priklausomybę nuo libsystemd ir išvengiama išorinių bibliotekų įkėlimo, kai jos nereikalingos.
- Suteikia daugiau lankstumo ir konkrečių programų reikalaujamų funkcijų valdymo.
- Supaprastina diagnostiką ir derinimą, nes galite tiesiogiai valdyti konkrečių funkcijų įgyvendinimą.
- Apskritai šis metodas skatina programų moduliškumą ir nepriklausomumą, gerina programinės įrangos kūrimo ir priežiūros lankstumą ir efektyvumą.
Kakleliai domina sužinoti daugiau apie tai, galite patikrinti išsamią informaciją Šioje nuorodoje.