systemd-Dienste härten: Was der Expositionswert dir nicht sagt

Führe systemd-analyze security auf einer typischen Maschine aus, und du bekommst eine Tabelle von Diensten mit einer Zahl neben jedem einzelnen. Es ist verlockend, diese Zahl als Urteil zu lesen. Die Handbuchseite sagt in ungewöhnlich direkten Worten, dass sie das nicht ist.

Was der Befehl tatsächlich misst

systemd-analyze security untersucht die Sicherheits- und Sandboxing-Einstellungen von Service-Units. Bekommt der Befehl einen Unit-Namen, zeigt er eine detaillierte Analyse; bekommt er keinen, untersucht er alle aktuell geladenen, langlaufenden Service-Units und gibt eine knappe Tabelle aus.

Er weist jeder relevanten Einstellung ein numerisches exposure level (Expositionsgrad) zu und berechnet daraus einen Gesamtwert für die Unit. Die Dokumentation beschreibt das als „eine Schätzung im Bereich 0.0…10.0, die angibt, wie exponiert ein Dienst sicherheitstechnisch ist”. Hohe Werte bedeuten, dass sehr wenig Sandboxing angewendet wurde. Niedrige Werte bedeuten striktes Sandboxing und starke Einschränkungen.

Bis hierhin liest sich das wie ein Scanner. Der wichtige Teil ist der Hinweis, der darauf folgt.

Die drei Grenzen, die das Handbuch unumwunden nennt

Es sieht nur, was systemd selbst implementiert. Die Dokumentation ist eindeutig: Der Befehl „analysiert nur die dienstbezogenen Sicherheitsfunktionen, die systemd selbst implementiert”, was bedeutet, dass „zusätzliche Sicherheitsmechanismen, die vom Code des Dienstes selbst angewendet werden, nicht berücksichtigt werden”. Ein Dienst, der intern seine Privilegien abgibt, sich selbst in ein chroot setzt oder einen eigenen seccomp-Filter anlegt, bekommt dafür überhaupt keine Anerkennung.

Ein hoher Wert bedeutet nicht verwundbar. Dieser Satz verdient es, vollständig zitiert zu werden, denn es ist der, den alle überspringen: Ein hohes exposure level „bedeutet weder, dass kein wirksames Sandboxing durch den Code des Dienstes selbst angewendet wird, noch dass der Dienst tatsächlich für entfernte oder lokale Angriffe verwundbar ist”. Was es sehr wohl anzeigt, ist, dass der Dienst „von zusätzlichen Einstellungen profitieren könnte”.

Einzelne Einstellungen lassen sich rückgängig machen. Das Handbuch warnt, dass viele Sandboxing-Einstellungen „einzeln umgangen werden können”, wenn sie nicht mit anderen kombiniert werden. Es nennt einen konkreten Fall: Ein Dienst, der das Privileg behält, Einhängepunkte anzulegen oder aufzulösen, kann viele der anderen Sandboxing-Optionen aus seinem eigenen Code heraus aushebeln. Das Werkzeug berücksichtigt einige dieser Zusammenhänge, aber die Dokumentation sagt klar, dass es nicht alle davon berücksichtigt.

Warum „kombiniert” das entscheidende Wort ist

Beim Beispiel mit den Einhängepunkten lohnt es sich zu verweilen, denn es verändert, wie du deine eigenen Ergebnisse lesen solltest.

Wenn eine Unit Einhängepunkte manipulieren kann, dann lassen sich Einschränkungen, die als Sichtbarkeit des Dateisystems ausgedrückt sind, potenziell vom Dienst selbst rückgängig machen. Die Einschränkung ist immer noch deklariert, und der Wert zählt sie weiterhin mit, aber ihr praktischer Nutzen hängt davon ab, dass daneben eine weitere Einstellung vorhanden ist.

Deshalb liefert ein Checklisten-Ansatz enttäuschende Ergebnisse. Die drei Direktiven auszuwählen, die den Wert am schnellsten senken, kann eine Konfiguration hinterlassen, die gut bewertet wird und schlecht hält. Die Schlussfolgerung der Dokumentation selbst lautet, dass jeder Dienst „die umfassendsten und striktesten Sandboxing- und Sicherheitseinstellungen verwenden sollte, die möglich sind”, und nicht eine Auswahl davon.

Wie man den Wert nutzt, ohne ihn falsch zu lesen

Eine brauchbare Lesart, die zu dem passt, was das Handbuch für das Werkzeug beansprucht:

Behandle ihn als Inventar, nicht als Audit. Er sagt dir, welche Schutzmaßnahmen auf systemd-Ebene fehlen. Das ist wirklich nützlich und günstig zu bekommen. Er sagt dir nicht, ob ein Dienst sicher ist.

Vergleiche dich mit dir selbst über die Zeit. Die verlässlichste Nutzung ist die Erkennung von Regressionen: Eine Unit, deren exposure level nach einem Paket-Update oder einer Konfigurationsänderung steigt, ist eine Untersuchung wert. Dieser Vergleich ist aussagekräftig, auch wenn die absolute Zahl kein Urteil ist.

Bewerte Dienste von Dritten nicht nach dem Wert. Zwei Dienste mit derselben Zahl können eine sehr unterschiedliche reale Exposition haben, weil das Werkzeug das Sandboxing nicht sehen kann, das einer von ihnen intern betreibt. Sie nach dem Wert zu sortieren würde den belohnen, der mehr deklariert, und den bestrafen, der mehr tut.

Fang mit den Units an, die tatsächlich erreichbar sind. Ein netzseitig exponierter Dienst mit hohem exposure level ist etwas anderes als ein lokaler Timer mit derselben Zahl. Der Wert weiß nicht, was was ist, und du schon.

Die ehrliche Zusammenfassung

systemd-analyze security ist ein gutes Werkzeug, das sich selbst genau beschreibt, was seltener ist, als es sein sollte. Es misst das Sandboxing auf systemd-Ebene, das du deklariert hast, auf einer Skala von 0 bis 10, und es sagt ausdrücklich, dass eine hohe Zahl kein Verwundbarkeitsbefund und eine niedrige Zahl kein Unbedenklichkeitszeugnis ist.

Nutze es, um fehlende Schutzmaßnahmen zu finden und Regressionen abzufangen. Kombiniere Einstellungen, statt die billigsten herauszupicken, denn das Handbuch warnt, dass isolierte Einschränkungen von innerhalb des Dienstes aufgehoben werden können. Und behalte im Kopf, dass die Zahl deine Konfiguration beschreibt, nicht deine Angriffsfläche.

Für die Schicht darunter behandelt unser Leitfaden zum Linux-Hardening Kernel-Parameter, sysctl und Mandatory Access Control.

Die Beschreibung des Befehls, der Expositionsbereich von 0.0 bis 10.0, die drei genannten Grenzen und das Beispiel mit den Einhängepunkten stammen aus der Handbuchseite von systemd-analyze in der mit systemd 255 ausgelieferten Fassung. Formulierung und Verhalten können sich zwischen systemd-Versionen ändern; sieh im Handbuch der Version nach, die du einsetzt. Dieser Artikel enthält kein Beispiel einer Befehlsausgabe, weil die Umgebung, in der er geschrieben wurde, systemd nicht als PID 1 ausführt, und eine erfundene Ausgabe ein echtes Ergebnis falsch dargestellt hätte.