În rândul dezvoltatorilor sistemului manager systemd se discută despre reducerea dependențelor bibliotecii libsystemd, care este legată nu doar de componentele systemd, ci și de multe aplicații externe. De exemplu, în Fedora, peste 150 de pachete utilizează libsystemd ca dependențe. Inițiatorul discuției consideră că includerea în libsystemd a bibliotecilor externe suplimentare, care nu sunt controlate de dezvoltatorii systemd, crește semnificativ suprafața de atac în cazul compromiterii bibliotecilor externe, așa cum s-a întâmplat cu biblioteca liblzma.
Pe lângă liblzma și glibc, în libsystemd sunt încărcate și bibliotecile libzstd, liblz4 și libgcrypt, menținerea securității cărora devine o sarcină critică. În libsystemd este disponibil accesul la 12 API-uri de bază (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path și sd-resolve) și apare situația în care o aplicație, de exemplu, care folosește libsystemd doar pentru a apela funcția sd_notify pentru a informa systemd despre schimbarea stării sau sd_journal pentru a înregistra date în jurnal, devine legată de toate celelalte biblioteci și gestionari API. Ca o soluție, se propune împărțirea libsystemd în mai multe biblioteci separate, fiecare responsabilă pentru API-uri distincte, ceea ce va permite încărcarea dependențelor externe doar acolo unde sunt necesare.
Dezvoltatorii systemd consideră că împărțirea nu este fezabilă, deoarece gestionarii prezenți în libsystemd sunt interconectați. Împărțirea va necesita un efort uriaș și va conduce fie la pierderi de eficiență, fie la necesitatea duplicării codului. Pentru a reduce memoria ocupată în libsystemd, recent s-a adoptat o modificare ce implementează încărcarea dinamică a bibliotecilor liblzma, libzstd și liblz4 prin apelul dlopen(), în situațiile în care funcțiile lor sunt cu adevărat necesare. O modificare similară va fi implementată și pentru libgcrypt începând cu următoarea versiune.
Această soluție a fost criticată, deoarece, în locul unei legături evidente și clare, încărcarea bibliotecilor externe va fi efectuată în mod implicit, complicând diagnosticul, deoarece legătura dintre apelurile API din libsystemd și apelurile funcțiilor din bibliotecile externe nu este evidentă. În sine, trecerea la încărcarea prin dlopen() nu schimbă arhitectura, ci doar ascunde componentele externe de cei care întrețin și de utilizatori.
Lenart Pottering și-a exprimat dezacordul ferm față de ideea de a împărți libsystemd în mai multe biblioteci, deoarece acest pas ar complica semnificativ utilizarea comună a codului în systemd și ar necesita mutarea tuturor handler-elor interne în categoria publică sau compilarea lor static în fiecare bibliotecă. În primul caz, ar apărea probleme în menținerea stabilității API-ului și a spațiilor de nume, iar în al doilea - o creștere a dimensiunii din cauza duplicării codului.
Încărcarea bibliotecilor externe doar la nevoie, realizată pentru următoarea versiune, este percepută de Lenart ca o strategie optimă. Problema complexității obținerii datelor despre bibliotecile încărcate dinamic se propune a fi rezolvată prin adăugarea de câmpuri suplimentare în fișierele ELF cu informații despre aceste dependențe dinamice, care pot fi procesate de debug-uri și afișate în ieșirea utilitarului readelf.
În ceea ce privește legătura cu libsystemd a unui număr mare de aplicații, Lenart a recomandat dezvoltatorilor de aplicații să nu încerce să încarce libsystemd pentru o singură funcție, ci să implementeze un handler al protocolului la nivel de aplicație. De exemplu, implementarea funcționalității sd_notify() este destul de trivială și poate fi realizată în câteva linii de cod folosind socket-uri UNIX (AF_UNIX). O astfel de implementare separată a sd_notify este disponibilă din 2017 pentru OpenSSH și a fost recent acceptată în ramura portabilă OpenSSH 9.8, al cărei release este programat pentru mijlocul verii.
Sursa: opennet.ro
