(meistens) Menschen fügen Schwachstellen nicht absichtlich ein, sie treten zufällig auf. Mit zunehmender Codemenge nimmt die Anzahl der Fehler zu. Aber es ist nicht nur die Größe - die Anzahl der Fehler steigt mit der Komplexität des Codes und steigt schneller als linear an. Mehr Code ist also eine schlechte Nachricht für die Sicherheit.
Die Angriffsfläche von systemd ist massiv größer als initd - die Standardkonfiguration hat mehrere Schnittstellen.
Ein großes Ärgernis ist für mich die Designphilosophie; Die Absicht ist, dass systemd Distributoren eine einheitlichere Möglichkeit bietet, Dienste zu integrieren. Dies bedeutet jedoch, den Systemadministratoren die Kontrolle über das System zu entziehen (über die Auswirkungen des Ersetzens eines komplexen, aber gut verstandenen Ökosystems hinaus). Es macht es absichtlich schwierig oder unmöglich, Dinge zu erreichen, die mit initd erreicht werden könnten (beachten Sie, dass es viele Optionen für Service-Manager gibt, die unter initd laufen - djb daemontools, upstart, initng, rund, procd, openrc .... Die meisten davon lösen die Parallelisierungs-/Abhängigkeitsprobleme, die das sysv-rc-Init-System einschränken).
Ein Großteil der Startlogik eines Unix-Systems ist in Shell-Skripten implementiert. Dies macht es viel einfacher, den Vorgang nicht nur zurückzuentwickeln, sondern auch zu instrumentieren und die Fähigkeiten zu erweitern. Systemd verschiebt mehr Logik in Binärdateien und verlässt sich mehr auf ein komplexes und schlecht dokumentiertes Aufbau.
Die Kombination aus absichtlich reduzierter Kontrolle durch den Systemadministrator und fehlender Unterstützung des Systemadministrators bei seiner Aufgabe erschwert es ihm, seine Arbeit zu erledigen - was die Gewährleistung der Sicherheit des Systems umfasst.
Eine weitere Folge all dieser Komplexität in PID 1 bedeutet, dass Sie Ihr System viel häufiger neu starten müssen. Zusätzlich zu den Auswirkungen auf die Verfügbarkeit bedeutet dies auch, Ihr System durch eine Reihe von Zwischenzuständen zu bewegen, die vorübergehend Schwachstellen aufdecken können, die auf einem homöostatischen System schwer zu erkennen sind. Die Verwendung von daemon-reexec, um dies zu umgehen, bringt eine Reihe neuer Probleme mit sich.
Das wohlwollende Diktator-für-Leben-Modell scheint für den Linux-Kernel gut zu funktionieren, aber so funktioniert der Rest der Open-Source-Industrie nicht. Tatsächlich ist es vielleicht die Ausnahme, die die Regel bestätigt – dass Open Source funktioniert, weil niemand das Sagen hat, nicht obwohl niemand das Sagen hat. Systemd übernimmt die Kontrolle über viel der Funktionalität in einem Linux-System, aber es operiert als relativ kleine Gemeinschaft. Und wie bei der pwnie-Auszeichnung scheint es etwas nach innen gerichtet zu sein:Es gibt nicht viele Augäpfel auf den Code:Niemand hört zu, wenn Bedenken über den Code geäußert werden.
Systemd ist eigentlich eine Sammlung mehrerer Teile, und damit ein Vergleich sinnvoll ist, müssen Sie die Teile vergleichen, die tatsächlich einander entsprechen.
Schauen wir uns zuerst SysV init an:Dies ist ein sehr kleines Programm, das als erster Prozess nach dem Booten ausgeführt wird, einige sehr grundlegende Einstellungen vornimmt und dann eine Konfigurationsdatei liest (/etc/inittab ) und startet ein oder mehrere darin konfigurierte Programme und startet sie optional neu, wenn sie beendet werden. Es öffnet auch einige Kommunikationskanäle (/dev/initctl , Signal-Handler), die es ermöglichen, den aktuellen Runlevel zu ändern, dessen Änderung dazu führt, dass einige andere Programme ausgeführt werden, wiederum wie in /etc/inittab konfiguriert .
Und das ist es. Offensichtlich hat das keine große Angriffsfläche, einfach weil es fast nichts tut. Auf der anderen Seite wird alles andere, was für die eigentliche Verwaltung eines typischen Systems erforderlich ist, an externe Programme delegiert:wie man einen bestimmten Dienst startet und stoppt (z. B. Webserver, Datenbank, Netzwerk ...), Abhängigkeiten zwischen Diensten (d. h. zuerst die Datenbank starten , erst dann der Webserver), komplexere Überwachung (Watchdog-Funktionalität), Privilege Dropping und Sandboxing, On-Demand-Service-Aktivierung (z. B. inetd), Mounten von Dateisystemen, ... Systemd integriert einen Großteil dieser Funktionalität und ist daher komplexer.
Die Integration dieser Dinge an einer zentralen Stelle hat nun ein großes Potenzial, die Gesamtkomplexität und Fragilität zu reduzieren und das System dadurch sicherer zu machen. Nehmen Sie die verschiedenen „Sandboxing“-Funktionen, darunter das Löschen von Berechtigungen, das Beschränken des Zugriffs auf bestimmte Verzeichnisse, private temporäre Verzeichnisse, das Einstellen separater Namespaces, die Netzwerkisolierung ... Für systemd sind diese ziemlich einfach als Teil der Einrichtung der Dienstumgebung zu implementieren, die - als Service Manager - sowieso tun müssen. Bei SysV-Init hingegen müsste ein separates Programm verwendet werden; in der Praxis wäre dies eine Reihe von Shell-Skripten, oder es würde in die einzelnen Dienste integriert, wodurch der "riskante" Code auf mehr Stellen verteilt wird.
Darüber hinaus bietet systemd dem Systemadministrator die Möglichkeit, diese Funktionen einfach einzurichten (ein paar Zeilen in einer Konfigurationsdatei) und entlastet ihn davon, sie selbst implementieren zu müssen (was in einigen Fällen sogar das Ändern und Neukompilieren von Diensten beinhalten kann!). In der Praxis bedeutet dies natürlich, dass sie überhaupt nicht verwendet werden. Aus Sicherheitssicht ist das ini-artige Konfigurationsformat auch ein Vorteil gegenüber den turing-complete-Shell-Skripten, die mit SysV-Init verwendet werden.
Was das Entwicklungsmodell hinter systemd betrifft:Ich sehe dies als Vorteil gegenüber der Alternative, da es einen zentralen Ort gibt, an dem die Entwicklung (und umfangreiche Tests!) stattfindet, was im Gegensatz zu der vorherigen Mischung aus hauptsächlich verteilungsspezifischem Code steht. Sogar der SysV-Init-Kern selbst unterschied sich zwischen den Distributionen, da sein Upstream als tot angesehen werden kann. Und im Gegensatz zu dem, was andere sagen, ist systemd Upstream tatsächlich sehr reaktionsschnell und offen für vernünftige Änderungswünsche.
Allerdings sehe ich eine Situation, in der die Dinge anders sind, nämlich wenn die von systemd bereitgestellten Funktionen nicht benötigt werden, beispielsweise wenn Sie einen Router oder ein einfaches Netzwerk-Gateway bauen möchten, bei dem die Menge der erforderlichen Dienste im Voraus bekannt ist und wird sich nie ändern. Auch dort möchten Sie vielleicht die benutzerfreundlichen Sandboxing-Funktionen nutzen, und dies ist ohnehin ein Sonderfall, der für die überwiegende Mehrheit der Systeme nicht gilt.