(většinou) lidé neinjektují zranitelnosti záměrně, objevují se náhodou. S rostoucím objemem kódu se zvyšuje počet defektů. Nejde však jen o velikost – s složitostí roste i počet chyb kódu a zvyšuje se rychleji než lineárně. Takže další kód je špatná zpráva pro bezpečnost.
Útočná plocha systemd je výrazně větší než initd – výchozí konfigurace má více rozhraní.
Velkou nepříjemností je pro mě filozofie designu; záměrem je, aby systemd poskytoval distributorům jednotnější způsob integrace služeb. To však znamená odebrání kontroly nad systémem od systémových administrátorů (mimo vliv nahrazení složitého, ale dobře srozumitelného ekosystému). Záměrně to ztěžuje nebo znemožňuje dosáhnout něčeho, co by se dalo udělat pomocí initd (všimněte si, že pro správce služeb běžících pod initd existuje mnoho možností - djb daemontools, upstart, initng, rund, procd, openrc.... Většina z nich řeší problémy s paralelizací/závislostí, které omezují inicializační systém sysv rc).
Velká část logiky spouštění unixového systému je implementována v shellových skriptech. Díky tomu je mnohem snazší nejen provést zpětnou analýzu operace, ale také ji instrumentovat a rozšířit možnosti. Systemd přesouvá více logiky do binárních souborů a více spoléhá na komplexní a špatně zdokumentované konfigurace.
Kombinace záměrného snižování úrovně kontroly ze strany správce systému a nepodpory správce systému v jeho úkolu jim ztěžuje plnění jejich práce – což zahrnuje zajištění bezpečnosti systému.
Další důsledek celé této složitosti v PID 1 znamená, že byste měli systém restartovat mnohem častěji. Kromě dopadu na dostupnost to také znamená přesun vašeho systému přes řadu přechodných stavů – což může dočasně odhalit zranitelnosti, které jsou na homeostatickém systému obtížně detekovatelné. Použití daemon-reexec k vyřešení tohoto problému přináší novou sadu problémů.
Zdá se, že model benevolentního diktátora na celý život funguje dobře pro linuxové jádro, ale takto nefunguje zbytek odvětví open source. Ve skutečnosti je to možná výjimka, která potvrzuje pravidlo - že open source funguje, protože nikdo nemá na starosti, ne přesto, že to nikdo neřídí. Systemd přebírá kontrolu nad množstvím funkce v linuxovém systému, přesto funguje jako relativně malá komunita. A podle ocenění pwnie to vypadá, že je to poněkud vnitřně zaměřené:na kód není mnoho očí:nikdo neposlouchá, když jsou v souvislosti s kódem vzneseny obavy.
Systemd je vlastně sbírka několika částí, a aby srovnání dávalo smysl, musíte porovnat části, které si skutečně odpovídají.
Podívejme se nejprve na SysV init:Jedná se o velmi malý program, který se po spuštění spustí jako první proces, který provede velmi základní nastavení a poté načte konfigurační soubor (/etc/inittab ) a spustí jeden nebo více programů v něm nakonfigurovaných, případně je restartuje, když se ukončí. Také otevírá některé komunikační kanály (/dev/initctl , obslužné rutiny signálů), které umožňují změnit aktuální úroveň běhu, jejíž změna povede ke spuštění některých dalších programů, opět podle konfigurace v /etc/inittab .
A to je vše. Je zřejmé, že to nemá velkou útočnou plochu, jednoduše proto, že nedělá téměř nic. Na druhou stranu, vše ostatní, co je potřeba pro skutečnou správu typického systému, je delegováno na externí programy:jak spustit a zastavit konkrétní službu (např. webový server, databáze, síť...), závislosti mezi službami (tj. nejprve spustit databázi , teprve potom webový server), složitější monitorování (funkce watchdog), zahazování oprávnění a sandboxing, aktivace služeb na vyžádání (např. inetd), připojování souborových systémů, ... Systemd integruje velkou část této funkce, a je tedy složitější.
Nyní má integrace těchto věcí na centrálním místě velký potenciál snížit celkovou složitost a křehkost, a tím zvýšit bezpečnost systému. Vezměte si různé funkce „sandboxing“, včetně zahození oprávnění, omezení přístupu k určitým adresářům, soukromých dočasných adresářů, nastavení samostatných jmenných prostorů, izolace sítě... Pro systemd je to docela snadné implementovat jako součást nastavení prostředí služeb, které - jako správce služeb - stejně musí udělat. Naproti tomu se SysV init by musel být použit samostatný program; v praxi by se jednalo o sadu skriptů shellu nebo by to bylo integrováno do jednotlivých služeb, čímž by se „rizikový“ kód rozložil na více míst.
Systemd navíc poskytuje správci systému prostředky pro snadné nastavení těchto funkcí (několik řádků v konfiguračním souboru), čímž je zbaví nutnosti je implementovat sami (což v některých případech může dokonce zahrnovat úpravu a překompilování služeb!). V praxi to samozřejmě znamená, že se vůbec nepoužívají. Z bezpečnostního hlediska je konfigurační formát ve stylu ini také výhodou oproti skriptům shellu Turing-complete, které se používají s init SysV.
Pokud jde o model vývoje za systemd:vidím to jako výhodu oproti alternativě, protože existuje jedno centrální místo, kde probíhá vývoj (a rozsáhlé testování!), což je v kontrastu s předchozí směsí převážně distribučně specifického kódu. I samotné init jádro SysV se mezi distribucemi lišilo, protože jeho upstream lze považovat za mrtvý. A na rozdíl od toho, co říkají ostatní, systemd upstream ve skutečnosti velmi reaguje a je otevřený rozumným požadavkům na změnu.
To znamená, že vidím jednu situaci, kdy jsou věci jinak, což je situace, kdy funkce poskytované systemd nejsou potřeba, například pokud chcete postavit router nebo jednoduchou síťovou bránu, kde je sada požadovaných služeb známa předem a se nikdy nezmění. I tam možná budete chtít využít snadno použitelné funkce sandboxingu, a toto je každopádně speciální případ, který neplatí pro velkou většinu systémů.