it-swarm.com.de

Was sind die Sicherheitsauswirkungen von systemd im Vergleich zu systemv init?

Ich fange gerade erst an, etwas über das Init-System zu lernen, daher kenne ich nur die High-Level-Eigenschaften von beiden.

Ich habe viel Aufhebens um systemd bemerkt, sogar einige Leute behaupten, dass systemd geschaffen wurde, um absichtlich Vunerabilitäten einzuführen!

Das Argument, das ich am häufigsten sehe, ist, dass systemd einen neuen, großen (und unbekannten) Angriffsvektor einführt. Andererseits scheint mir ein System wie systemd tatsächlich eine gute Sache zu sein, da es sich im Gegensatz zu Ad-hoc-Init-Skripten um standardisierten Code handelt. In dieser Hinsicht sehe ich Ähnlichkeiten mit dem Kernel. Sicher, jeder kann sein eigenes einfach zu lesendes Betriebssystem erstellen, aber ist es nicht besser, denselben Code wiederzuverwenden, damit eine große Anzahl von Augäpfeln ihn überwacht?

Bin ich hier auf dem richtigen Weg? Gibt es Probleme, die ich nicht in Betracht ziehe?

16
David Varela

(meistens) Menschen injizieren Schwachstellen nicht absichtlich, sie treten zufällig auf. Mit zunehmendem Codevolumen steigt die Anzahl der Fehler. Aber es ist nicht nur die Größe - die Anzahl der Fehler nimmt mit der Komplexität des Codes zu und nimmt schneller als linear zu. Mehr Code ist also eine schlechte Nachricht für die Sicherheit.

Die Angriffsfläche von systemd ist massiv größer als initd - die Standardkonfiguration verfügt über mehrere Schnittstellen.

Ein großes Ärgernis für mich ist die Designphilosophie; Die Absicht ist, dass systemd den Händlern eine einheitlichere Möglichkeit bietet, Dienste zu integrieren. Dies bedeutet jedoch, den Systemadministratoren die Kontrolle über das System zu entziehen (über die Auswirkungen des Austauschs eines komplexen, aber gut verstandenen Ökosystems hinaus). Es macht es absichtlich schwierig oder unmöglich, etwas zu erreichen, was mit initd möglich ist (beachten Sie, dass es viele Optionen für Service-Manager gibt, die unter initd ausgeführt werden - djb daemontools, upstart, initng, rund, procd, openrc .... Die meisten davon lösen sich die Paralellisierungs-/Abhängigkeitsprobleme, die das sysv rc init-System einschränken).

Ein Großteil der Logik des Starts eines Unix-Systems ist in Shell-Skripten implementiert. Dies macht es viel einfacher, den Betrieb nicht nur zurückzuentwickeln, sondern auch zu instrumentieren und die Funktionen zu erweitern. Systemd verschiebt mehr Logik in Binärdateien und stützt sich mehr auf eine komplexe und schlecht dokumentierte Konfiguration.

Die Kombination aus einer absichtlichen Reduzierung des Kontrollniveaus durch den Systemadministrator und der Nichtunterstützung des Systemadministrators bei seiner Aufgabe erschwert es ihnen, ihre Arbeit zu erledigen - was die Gewährleistung der Sicherheit des Systems umfasst.

Eine weitere Folge dieser Komplexität in PID 1 ist, dass Sie Ihr System viel häufiger neu starten müssen. Zusätzlich zu den Auswirkungen auf die Verfügbarkeit bedeutet dies auch, dass Sie Ihr System durch eine Reihe von Zwischenzuständen bewegen. Dies kann vorübergehend Schwachstellen aufdecken, 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 Modell des wohlwollenden Diktators fürs Leben scheint für den Linux-Kernel gut zu funktionieren, aber so funktioniert der Rest der Open-Source-Industrie nicht. In der Tat ist es vielleicht die Ausnahme, die die Regel bestätigt - dass Open Source funktioniert, weil niemand verantwortlich ist, nicht obwohl niemand verantwortlich ist. Systemd übernimmt die Kontrolle über eine Menge der Funktionalität in einem Linux-System, arbeitet jedoch als relativ kleine Community. Und laut der Auszeichnung pwnie scheint es etwas nach innen zu schauen: Der Code enthält nicht viele Augäpfel: Niemand hört zu, wenn Bedenken hinsichtlich des Codes geäußert werden.

18
symcbean

Systemd ist eigentlich eine Sammlung mehrerer Teile, und damit ein Vergleich sinnvoll ist, müssen Sie die Teile vergleichen, die tatsächlich miteinander korrespondieren.

Schauen wir uns zuerst SysV init an: Dies ist ein sehr kleines Programm, das als erster Prozess nach dem Start ausgeführt wird, der einige sehr grundlegende Einstellungen vornimmt, dann eine Konfigurationsdatei (/etc/inittab) Liest und ein oder mehrere darin konfigurierte Programme startet , optional neu starten, wenn sie beenden. Es werden auch einige Kommunikationskanäle geöffnet (/dev/initctl, Signalhandler), die es ermöglichen, den aktuellen Runlevel zu ändern. Eine Änderung davon führt dazu, dass einige andere Programme ausgeführt werden, wie in /etc/inittab.

Und das ist es. Offensichtlich hat dies keine große Angriffsfläche, einfach weil es fast nichts tut. Auf der anderen Seite wird alles andere, was für die tatsächliche Verwaltung eines typischen Systems erforderlich ist, an externe Programme delegiert: Starten und Stoppen eines bestimmten Dienstes (z. B. Webserver, Datenbank, Netzwerk ...), Abhängigkeiten zwischen Diensten (dh Starten der Datenbank zuerst) , nur dann der Webserver), komplexere Überwachung (Watchdog-Funktionalität), Löschen von Berechtigungen und Sandboxing, Aktivierung von On-Demand-Diensten (z. B. inetd), Mounten von Dateisystemen, ... Systemd integriert einen Großteil dieser Funktionalität und ist daher komplexer.

Die Integration dieser Dinge an einem zentralen Ort bietet ein großes Potenzial, um die Komplexität und Fragilität insgesamt zu verringern und dadurch das System sicherer zu machen. Nutzen Sie die verschiedenen "Sandboxing" -Funktionen, einschließlich Löschen von Berechtigungen, Einschränken des Zugriffs auf bestimmte Verzeichnisse, private temporäre Verzeichnisse, Einstellen separater Namespaces, Netzwerkisolation ... Für systemd sind diese im Rahmen der Einrichtung der Dienstumgebung recht einfach zu implementieren - als Service Manager - muss sowieso tun. Im Gegensatz dazu müsste bei SysV init ein separates Programm verwendet werden. In der Praxis wäre dies eine Reihe von Shell-Skripten oder würde in die einzelnen Dienste integriert, wodurch der "riskante" Code auf mehrere Stellen verteilt würde.

Darüber hinaus bietet systemd dem Systemadministrator die Möglichkeit, diese Funktionen einfach einzurichten (einige Zeilen in einer Konfigurationsdatei), sodass sie nicht selbst implementiert werden 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 Sicherheitsgründen ist das Konfigurationsformat im INI-Stil auch ein Vorteil gegenüber den 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, im Gegensatz zu der vorherigen Mischung aus größtenteils verteilungsspezifischem Code. Sogar der SysV-Init-Kern selbst unterschied sich zwischen den Verteilungen, da sein Upstream als tot angesehen werden kann. Und im Gegensatz zu den Aussagen anderer ist systemd upstream tatsächlich sehr reaktionsschnell und offen für vernünftige Änderungswünsche.

Ich sehe jedoch eine Situation, in der die Dinge anders sind, wenn die von systemd bereitgestellten Funktionen nicht benötigt werden, z. B. wenn Sie einen Router oder ein einfaches Netzwerk-Gateway erstellen möchten, bei dem die erforderlichen Dienste im Voraus bekannt sind und wird sich nie ändern. Selbst dort möchten Sie möglicherweise die benutzerfreundlichen Sandbox-Funktionen nutzen, und dies ist ohnehin ein Sonderfall, der für die überwiegende Mehrheit der Systeme nicht gilt.

5
Marc Schütz