Quali sono le implicazioni per la sicurezza di systemd rispetto a systemv init?

(soprattutto) le persone non iniettano le vulnerabilità deliberatamente, si verificano per caso. All'aumentare del volume di codice aumenta il numero di difetti. Ma non solo le dimensioni: il numero di bug aumenta con la complessità del codice e aumenta più rapidamente che linearmente. Quindi più codice è una cattiva notizia per sicurezza.

La superficie di attacco di systemd è enormemente più grande di initd - la configurazione di default ha più interfacce.

Un grande fastidio per me è la filosofia del design; l'intenzione è che systemd offra ai distributori un modo più unificato per integrare i servizi. Ma ciò significa rimuovere il controllo del sistema dagli amministratori del sistema (oltre l'impatto della sostituzione di un ecosistema complesso ma ben compreso). Rende deliberatamente difficile o impossibile realizzare cose che potrebbero essere fatte con initd (si noti che ci sono molte opzioni per i service manager che funzionano con initd - djb daemontools, upstart, initng, rund, procd, openrc .... La maggior parte delle quali risolve i problemi di paralellizzazione / 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 la retroingegnerizzazione dell'operazione, ma anche la sua strumentazione ed estensione delle funzionalità. Systemd trasferisce più logica in binari e si basa più su una configurazione complessa e scarsamente documentata .

La combinazione di ridurre deliberatamente il livello di controllo da parte dell'amministratore di sistema e non riuscire a supportare l'amministratore di sistema nelle loro attività rende più difficile per loro svolgere il proprio lavoro, che comprende la sicurezza del sistema.

Un'ulteriore conseguenza di tutta questa complessità in PID 1 significa che è necessario riavviare il sistema molto più frequentemente. Oltre all'impatto sulla disponibilità, ciò significa anche spostare il sistema attraverso una serie di stati provvisori, che possono rivelare temporaneamente vulnerabilità difficili da rilevare su un sistema omeostatico. L'uso di daemon-reexec per ovviare a questo porta una nuova serie di problemi.

Il modello benevolo-dittatore-per-vita sembra funzionare bene per il kernel Linux, ma non è così che funziona il resto del settore open source. In effetti è forse l'eccezione che conferma la regola: l'open source funziona perché nessuno è responsabile, non nonostante nessuno sia al comando. Systemd assume il controllo su un lotto della funzionalità in un sistema Linux, ma funziona come una comunità relativamente piccola. E come per il premio pwnie sembra un po 'di sguardo interiore: non ci sono molti di bulbi oculari sul codice: nessuno sta ascoltando quando vengono sollevati dubbi sul codice.

Systemd è in realtà una raccolta di diverse parti e, per un confronto, è necessario confrontare le parti che effettivamente corrispondono tra loro.

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 configurati in esso , opzionalmente riavviandoli quando escono. Apre anche alcuni canali di comunicazione ( /dev/initctl , gestori di segnale) che rendono possibile modificare il runlevel corrente, un cambiamento del quale risulterà in altri programmi da eseguire, sempre come configurato in /etc/inittab .

E questo è tutto. Ovviamente, questo non ha una grande superficie d'attacco, semplicemente perché non fa quasi nulla. Sul rovescio della medaglia, tutto il resto necessario per la gestione di un sistema tipico è delegato a programmi esterni: come avviare e interrompere un servizio specifico (ad es. Server web, database, rete ...), dipendenze tra servizi (ad esempio, avviare prima il database , solo allora il web server), monitoraggio più complesso (funzionalità watchdog), eliminazione dei privilegi e sandboxing, attivazione del servizio su richiesta (ad esempio inetd), montaggio di filesystem, ... Systemd integra molte di queste 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. Assumere le varie funzionalità di "sandboxing", tra cui eliminazione dei privilegi, limitazione dell'accesso a determinate directory, directory temporanee private, impostazioni spazi dei nomi separati, isolamento della rete ... Per systemd, queste sono piuttosto facili da implementare come parte della configurazione dell'ambiente dei servizi, che - come un gestore di servizi - deve fare comunque. Al contrario, con SysV init, sarebbe necessario utilizzare un programma separato; in pratica questo sarebbe un insieme di script di shell, o sarebbe integrato nei singoli servizi, diffondendo così il codice "rischioso" su più punti.

Inoltre, systemd fornisce all'amministratore di sistema i mezzi per configurare facilmente queste funzionalità (poche righe in un file di configurazione), sollevandole dal doverle implementare da sé (che in alcuni casi può anche comportare la modifica e la ricompilazione dei servizi!) . Certo, in pratica questo significa che non vengono usati affatto. Dal punto di vista della sicurezza, il formato di configurazione ini-style è anche un vantaggio rispetto agli script di shell completi di turing che vengono utilizzati con SysV init.

Per quanto riguarda il modello di sviluppo dietro systemd: vedo questo come un vantaggio rispetto all'alternativa, perché c'è un posto centrale in cui avviene lo sviluppo (e test estensivi!), che è in contrasto con il precedente mix di distribuzione principalmente specifica codice. Anche il core init di SysV stesso 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 richieste di cambiamento ragionevoli.

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 vuole costruire un router o un semplice gateway di rete in cui l'insieme dei servizi richiesti è conosciuto in anticipo e non cambierà mai. Anche lì, potresti voler sfruttare le funzionalità di sandboxing di facile utilizzo, e questo è comunque un caso speciale che non si applica alla maggior parte dei sistemi.

Per quanto riguarda la cosa dell'occhio umano - storicamente gli script di init RC al centro di RHEL e tale, il clone di base "SYS V" init, non era qualcosa che è stato scritto con estrema robustezza in mente, non è come hanno fatto una lavagna progettazione della macchina di stato in là. E non saresti stato in grado di inviare solo patch per la maggior parte delle distro importanti. Se non ci sono specifiche scritte e un design sw reale sul tuo init, scoprirai che le persone hanno paura di cambiarlo.

Tuttavia, l'impatto della fragilità era piuttosto basso, così come le dimensioni delle singole attività. Esegui una sceneggiatura. Esegui il prossimo. Non avere file temporanei. Essere apolidi internamente tranne che per un segnalino corsa che fa andare le cose sia verso il "bersaglio" desiderato, sia verso il contrario.

Non c'erano interfacce tranne il comando init o telinit. In un corretto unix, init 0 simpy termina init, lasciandoti in un limbo. Linux (per comodità e per facilitare la vita a persone che non leggono un manuale) si era già allontanato dal progetto semplicistico, e sembra che non ci sia mai stata la considerazione (mi dispiace) che il clone di init debba essere una specie di "MIL" -SPEC "qualità.

Ora stiamo avendo la stessa cosa, e di nuovo quelle preoccupazioni non sono le più elevate, ma ora ci vuole una parte molto più grande nell'elaborazione delle attività, nel modo in cui si interfaccia con il kernel, in quanto è accessibile a non root utenti e in quanto elabora l'input al di fuori di quando viene eseguita un'attività di avvio.

Queste sono semplici differenze. Il problema è che, ancora una volta, aspetti come l'irrigidimento o il fallimento dello stato operativo sicuro / fallito non sono considerati elementi fondamentali. Ci sono alcune misure in questa direzione (ad esempio, se risolti automaticamente si respawn se viene eliminato dal traffico malevolo) ma non molto .

Ora lasciamo presumere che il processo di sviluppo e la reattività alle preoccupazioni cambieranno. Quello dovrebbe essere bello. (avendo lavorato con poche alternative non credo che sarebbe successo, dal momento che nessuno degli altri è stato ostile in alcun modo)

Quindi rimaniamo con un problema: la cosa a molti occhi è discutibile. Nel normale sistema di init, a causa della mancanza di interfacce, il "vettore di attacco" sta ricevendo uno script di init, che solo root può fare. Poi è permesso fare qualsiasi cosa ritenga necessario, e tu sei alla mercé dell'autore per quanto riguarda il fatto di lasciar andare i privati. Se sa come usare su, sarà su, se non lo fa allora sarà sudo, e così via. Ma l'unico modo in cui attaccherà il tuo sistema init è se inserisce qualcosa che sovrascrive il binario / script. Non riuscirà nemmeno a "persistere" dentro , dal momento che qualsiasi variabile che esporterebbe verrebbe schiacciata quando verrà eseguito lo script successivo. La lingua (idealmente, solo POSIX) è al punto in cui si ottiene un buco di secondo per ogni 10 anni, e normalmente nessuno. E, voglio sottolineare un po '- c'è solo troppo poco per attaccare e nessun modo in cui può ottenere un attacco dopo che il sistema è attivo.

Quelle differenze ci sono. Possono essere motivo di preoccupazione o no. Ma l'argomento della "base di codice condivisa" è per lo più discutibile. L'argomento per cui ti sei sbarazzato dei brutti wrapper di priv-drop ha due punti di discussione. uno, che quelli sono o design difettoso (nat locale è una cosa) o necessità (ssh) e due, che nel mondo sw abbiamo appreso che per qualsiasi problema relativo alla sicurezza dobbiamo dare la priorità ai nostri peggiori problemi, e piuttosto esagerare risolvendolo che no Questo non sta succedendo.

In questo momento poche persone sono alla ricerca di exploit, ma non è che questo sia un argomento interessante per i ricercatori del settore. Una volta che ciò accade e si incontra con una base di miliardi di dispositivi installati, che non ottengono patch, sono un po 'preoccupato. Potremmo avere benefici nel mondo tecnologico. Per le persone che traggono beneficio da qualsiasi cosa i nostri sistemi facciano, ci sono dei benefici nella misura in cui i servizi di riavvio automatico stanno diventando più comuni (perché apparentemente era troppo difficile leggere su daemontools per configurazioni non HA), ma non voglio essere intorno e ho bisogno di giustificare se ripetiamo alcune merde come CodeRed nel nostro init.

Mostrami come chiudere che ora in contrasto con l'impronta di un singolo (!) script di shell eseguito all'avvio. Le contromisure sono diventate un po 'più complicate. E per quanto riguarda il daemon-reexec, mi chiedo ancora perché un zypper ps -s vedrà ancora in seguito le vecchie parti systemd nella memoria.

Ho saltato il confronto con SMF - che uno degli sviluppatori systemd ha chiamato "Solaris" o alcuni paralleli ad AIX, come la registrazione binaria e SRC. SMF ha avuto un processo di progettazione molto aperto, inclusivo, ponderato e documentato e penso che siano le grandi differenze. Non ho idea di come sarà mai riparato.