Tra gli sviluppatori del gestore di sistema systemd c'è un dibattito riguardo alla riduzione delle dipendenze della libreria libsystemd, che è collegata non solo ai componenti di systemd, ma anche a molte applicazioni esterne. Ad esempio, in Fedora oltre 150 pacchetti utilizzano libsystemd come dipendenza. L'iniziatore del dibattito sostiene che l'inclusione di ulteriori librerie di terze parti in libsystemd, che non sono controllate dagli sviluppatori di systemd, aumenta notevolmente la superficie di attacco in caso di compromissione delle librerie di terze parti, come accaduto con la libreria liblzma.
Oltre a liblzma e glibc, in libsystemd vengono caricate anche le librerie libzstd, liblz4 e libgcrypt, la cui sicurezza diventa una priorità critica. Libsystemd fornisce accesso a 12 API fondamentali (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path e sd-resolve) e si verifica una situazione in cui un'applicazione, ad esempio, che utilizza libsystemd solo per chiamare la funzione sd_notify per informare systemd del cambiamento di stato o sd_journal per registrare dati nel log, si collega a tutte le altre librerie e gestori API. Come soluzione, si propone di suddividere libsystemd in diverse librerie separate, responsabili di singole API, consentendo il caricamento delle dipendenze di terze parti solo dove necessario.
Gli sviluppatori di systemd ritengono che la suddivisione non sia opportuna, poiché gli handler presenti in libsystemd sono interconnessi. La separazione richiederebbe un enorme lavoro e porterebbe o a una perdita di efficienza, oppure alla necessità di duplicare codice. Recentemente, per ridurre l'uso della memoria in libsystemd, è stata introdotta una modifica con l'implementazione del caricamento dinamico delle librerie liblzma, libzstd e liblz4 tramite la chiamata dlopen(), nelle situazioni in cui le loro funzioni sono effettivamente necessarie. Una modifica simile sarà implementata anche per libgcrypt a partire dal prossimo rilascio.
Tale soluzione ha suscitato critiche, poiché invece di un'associazione esplicita e evidente, il caricamento delle librerie esterne avverrà in modo non esplicito, complicando la diagnostica, poiché non è chiara la connessione tra le chiamate API di libsystemd e le funzioni delle librerie esterne. Il passaggio stesso al caricamento tramite dlopen() non cambia l'architettura, ma nasconde soltanto i componenti esterni agli sviluppatori e agli utenti.
Lenart Pottering ha espresso un categorico disaccordo sull'idea di suddividere libsystemd in più librerie, poiché tale passo complicerebbe notevolmente la condivisione del codice in systemd e richiederebbe di rendere tutti i gestori interni pubblici o di compilarli staticamente in ciascuna libreria. Nel primo caso, sorgerebbero problemi nel mantenere la stabilità dell'API e degli spazi dei nomi, mentre nel secondo si avrebbe un aumento delle dimensioni a causa della duplicazione del codice.
La strategia di caricare librerie esterne solo quando necessario, implementata per la prossima versione, è considerata da Lenart come l'approccio ottimale. Si propone di risolvere il problema della complessità nel reperire dati sulle librerie caricate dinamicamente aggiungendo nei file ELF campi aggiuntivi con informazioni su tali dipendenze dinamiche, che possono essere elaborate dai debugger e visualizzate nell'output dello strumento readelf.
Per quanto riguarda il collegamento di un gran numero di applicazioni a libsystemd, Lenart ha raccomandato agli sviluppatori di applicazioni di non cercare di caricare libsystemd per una sola funzione, ma di implementare un gestore del protocollo a livello di applicazione. Ad esempio, l'implementazione della funzionalità sd_notify() è abbastanza semplice e può essere realizzata in poche righe di codice utilizzando i socket UNIX (AF_UNIX). Una tale implementazione isolata di sd_notify è disponibile per OpenSSH dal 2017 ed è stata recentemente accettata nella versione portabile di OpenSSH 9.8, il cui rilascio è previsto per metà estate.
Fonte: opennet.ru
