(principalmente) le persone non iniettano vulnerabilità deliberatamente, si verificano per caso. All'aumentare del volume del codice, aumenta il numero di difetti. Ma non si tratta solo di dimensioni:il numero di bug aumenta con la complessità del codice e aumenta più velocemente che linearmente. Quindi più codice è una cattiva notizia per la sicurezza.
La superficie di attacco di systemd è enormemente più ampia di initd:la configurazione predefinita ha più interfacce.
Un grande fastidio per me è la filosofia del design; l'intenzione è che systemd fornisca un modo più unificato per i distributori di integrare i servizi. Ma questo significa rimuovere il controllo sul sistema dagli amministratori di sistema (oltre all'impatto della sostituzione di un ecosistema complesso ma ben compreso). Rende deliberatamente difficile o impossibile ottenere cose che potrebbero essere fatte con initd (si noti che ci sono molte opzioni per i gestori di servizi che girano sotto initd - djb daemontools, upstart, initng, rund, procd, openrc.... La maggior parte risolve i problemi di parallelizzazione/dipendenza che limitano il sistema sysv rc init).
Gran parte della logica dell'avvio di un sistema unix è implementata negli script di shell. Ciò rende molto più semplice non solo il reverse engineering dell'operazione, ma anche la sua strumentazione ed estensione delle capacità. Systemd sposta più logica nei binari e si affida maggiormente a un complesso e scarsamente documentato configurazione.
La combinazione di ridurre deliberatamente il livello di controllo da parte dell'amministratore di sistema e non supportare l'amministratore di sistema nel suo compito rende più difficile per loro svolgere il proprio lavoro, che comprende garantire la sicurezza del sistema.
Un'ulteriore conseguenza di tutta questa complessità nel PID 1 significa che dovresti riavviare il tuo sistema molto più frequentemente. Oltre all'impatto sulla disponibilità, ciò significa anche spostare il sistema attraverso una serie di stati intermedi, che possono esporre temporaneamente vulnerabilità difficili da rilevare su un sistema omeostatico. L'uso di daemon-reexec per risolvere questo problema porta una nuova serie di problemi.
Il modello del benevolo dittatore per la vita sembra funzionare bene per il kernel Linux, ma non è così che opera il resto dell'industria open source. In effetti è forse l'eccezione che conferma la regola - che l'open source funziona perché nessuno è al comando, non nonostante nessuno lo sia. Systemd assume il controllo su un lotto delle funzionalità in un sistema Linux, tuttavia opera come una comunità relativamente piccola. E come per il pwnie award sembra essere un po' introverso:non ci sono molti occhi sul codice:nessuno ascolta quando vengono sollevate preoccupazioni sul codice.
Systemd è in realtà una raccolta di più parti e, affinché un confronto abbia senso, devi confrontare le parti che effettivamente corrispondono l'una all'altra.
Diamo prima un'occhiata a SysV init:questo è un programma molto piccolo che viene eseguito come primo processo dopo l'avvio che esegue alcune impostazioni di base, quindi legge un file di configurazione (/etc/inittab ) e avvia uno o più programmi ivi configurati, eventualmente riavviandoli alla loro uscita. Apre anche alcuni canali di comunicazione (/dev/initctl , gestori di segnali) che consentono di modificare il runlevel corrente, una modifica del quale comporterà l'esecuzione di altri programmi, sempre come configurato in /etc/inittab .
E questo è tutto. Ovviamente, questo non ha una grande superficie di attacco, semplicemente perché non fa quasi nulla. D'altra parte, tutto ciò che è necessario per gestire effettivamente un sistema tipico è delegato a programmi esterni:come avviare e arrestare un servizio specifico (ad es. Web server, database, rete...), dipendenze tra i servizi (ad esempio avviare prima il database , solo quindi il server Web), monitoraggio più complesso (funzionalità watchdog), eliminazione dei privilegi e sandboxing, attivazione del servizio su richiesta (ad es. inetd), montaggio di filesystem, ... Systemd integra gran parte di questa funzionalità ed è quindi più complesso.
Ora, l'integrazione di queste cose in un luogo centrale ha un grande potenziale per ridurre la complessità e la fragilità complessive e quindi rendere il sistema più sicuro. Prendi le varie funzionalità di "sandboxing", tra cui l'eliminazione dei privilegi, la limitazione dell'accesso a determinate directory, directory temporanee private, impostazioni di spazi dei nomi separati, isolamento della rete ... Per systemd, questi sono abbastanza facili da implementare come parte della configurazione dell'ambiente dei servizi, che - come responsabile del servizio - deve fare comunque. Al contrario, con SysV init, dovrebbe essere usato un programma separato; in pratica si tratterebbe di un insieme di script di shell, oppure verrebbe integrato nei singoli servizi, spargendo così il codice "rischioso" in più posti.
Inoltre, systemd fornisce all'amministratore di sistema i mezzi per impostare facilmente queste funzionalità (poche righe in un file di configurazione), sollevandolo dal doverle implementare da solo (che in alcuni casi può anche comportare la modifica e la ricompilazione dei servizi!). Naturalmente, in pratica ciò significa che non vengono utilizzati affatto. Da un punto di vista della sicurezza, il formato di configurazione ini-style è anche un vantaggio rispetto agli script di shell turing-complete utilizzati con SysV init.
Per quanto riguarda il modello di sviluppo alla base di systemd:lo vedo come un vantaggio rispetto all'alternativa, perché esiste un luogo centrale in cui avviene lo sviluppo (e test approfonditi!), Che è in contrasto con la precedente miscela di codice specifico per lo più della distribuzione. Anche lo stesso SysV init core differiva tra le distribuzioni, perché il suo upstream può essere considerato morto. E contrariamente a quanto dicono gli altri, systemd upstream è in realtà molto reattivo e aperto a ragionevoli richieste di modifica.
Detto questo, posso vedere una situazione in cui le cose sono diverse, ovvero quando le funzionalità fornite da systemd non sono necessarie, ad esempio se si desidera creare un router o un semplice gateway di rete in cui l'insieme dei servizi richiesti è noto in anticipo e non cambierà mai. Anche lì, potresti voler sfruttare le funzionalità di sandboxing facili da usare, e questo è comunque un caso speciale che non si applica alla stragrande maggioranza dei sistemi.