Sicherung Ihrer Dienste

Eines der Kernmerkmale von Unix-Systemen ist die Idee der Privilegientrennung zwischen den verschiedenen Komponenten des Betriebssystems.
Viele Systemdienste werden unter ihren eigenen Benutzer-IDs ausgeführt, was ihre Möglichkeiten und damit die Auswirkungen auf das Betriebssystem einschränkt, falls sie ausgenutzt werden.

Diese Art der Privilegientrennung bietet jedoch nur einen sehr grundlegenden Schutz, da auf diese Weise ausgeführte Systemdienste im Allgemeinen immer noch mindestens so viel tun können wie ein normaler lokaler Benutzer, wenn auch nicht so viel wie root.
Aus Sicherheitsgründen ist es jedoch sehr interessant, die Möglichkeiten von Diensten noch weiter einzuschränken und einige Dinge abzuschalten, die normale Benutzer tun dürfen.

Eine gute Möglichkeit, die Auswirkungen von Diensten zu begrenzen, ist der Einsatz von MAC-Technologien wie SELinux.
Wenn Sie daran interessiert sind, Ihren Server abzusichern, ist die Ausführung von SELinux eine sehr gute Idee. systemd ermöglicht es Entwicklern und Administratoren, unabhängig von einem MAC zusätzliche Einschränkungen auf lokale Dienste anzuwenden.
Unabhängig davon, ob Sie SELinux nutzen können, können Sie daher immer noch bestimmte Sicherheitsbeschränkungen für Ihre Dienste durchsetzen.

Systemd absichern

Diese systemd-Funktionen wurden so konzipiert, dass sie so einfach wie möglich zu verwenden sind, um sie für Administratoren und Upstream-Entwickler attraktiv zu machen:

Isolieren von Diensten vom Netzwerk
Service-private /tmp
Verzeichnisse als schreibgeschützt oder für Dienste unzugänglich erscheinen lassen
Funktionen von Diensten wegnehmen
Verbieten von Forking, Einschränkung der Dateierstellung für Dienste
Steuern des Geräteknotenzugriffs auf Dienste

Alle hier beschriebenen Optionen sind in den Manpages von systemd dokumentiert, insbesondere in systemd.exec(5)

Alle diese Optionen sind auf allen systemd-Systemen verfügbar, unabhängig davon, ob SELinux oder ein anderer MAC aktiviert ist oder nicht.
Alle diese Optionen sind relativ günstig, also nutze sie im Zweifelsfall.
Auch wenn Sie denken, dass Ihr Dienst nicht in /tmp schreibt und daher die Aktivierung von PrivateTmp=yes (wie unten beschrieben) möglicherweise nicht erforderlich ist, ist es aufgrund der heutigen komplexen Software immer noch vorteilhaft, diese Funktion zu aktivieren, einfach weil Sie auf Bibliotheken verlinken (und Plug-Ins für diese Bibliotheken), die Sie nicht kontrollieren, benötigen möglicherweise doch temporäre Dateien. Beispiel: Sie wissen nie, welche Art von NSS-Modul Ihre lokale Installation aktiviert hat und was dieses NSS-Modul mit /tmp macht.

Diese Optionen sind hoffentlich sowohl für Administratoren interessant, um ihre lokalen Systeme zu sichern, als auch für Upstream-Entwickler, um ihre Dienste standardmäßig sicher bereitzustellen. Wir empfehlen Upstream-Entwicklern dringend, diese Optionen standardmäßig in ihren Upstream-Serviceeinheiten zu verwenden.
Sie sind sehr einfach zu bedienen und bieten große Vorteile für die Sicherheit.

systemd Isolieren von Diensten vom Netzwerk
systemd Dienst-Privat /tmp=
systemd Verzeichnisse als schreibgeschützt oder für Dienste nicht zugänglich machen
systemd Fähigkeiten von Diensten wegnehmen
systemd Verbieten von Forking, Einschränkung der Dateierstellung für Dienste
Ressourcenlimits können verwendet werden, um bestimmte Sicherheitslimits auf ausgeführte Dienste anzuwenden.
In erster Linie sind Ressourcengrenzen für die Ressourcenkontrolle (wie der Name schon sagt ...) und nicht so sehr für die Zugriffskontrolle nützlich.
Zwei davon können jedoch nützlich sein, um bestimmte Betriebssystemfunktionen zu deaktivieren:
RLIMIT_NPROC und RLIMIT_FSIZE können verwendet werden, um das Forking zu deaktivieren und das Schreiben von Dateien mit einer Größe > 0 zu deaktivieren:

...
[Service]
ExecStart=...
LimitNPROC=1
LimitFSIZE=0
...

Beachten Sie, dass dies nur funktioniert, wennb der fragliche Dienst Privilegien aufgibt und unter einer eigenen (Nicht-Root-) Benutzer-ID läuft oder die CAP_SYS_RESOURCE-Fähigkeit aufgibt, zum Beispiel über CapabilityBoundingSet=, wie oben beschrieben.
Ohne dies könnte ein Prozess einfach das Ressourcenlimit wieder erhöhen und somit jegliche Wirkung zunichte machen.

Vorbehalt: LimitFSIZE= ist ziemlich brutal. Wenn der Dienst versucht, eine Datei mit einer Größe > 0 zu schreiben, wird er sofort mit dem SIGXFSZ beendet, der den Prozess beendet, wenn er nicht gefangen wird. Außerdem ist das Erstellen von Dateien mit der Größe 0 weiterhin erlaubt, auch wenn diese Option verwendet wird.

systemd Steuern des Geräteknotenzugriffs auf Dienste
Geräteknoten sind eine wichtige Schnittstelle zum Kernel und seinen Treibern. Da Treiber in der Regel viel weniger Tests und Sicherheitsüberprüfungen unterzogen werden als der Kernel, sind sie oft ein wichtiger Einstiegspunkt für Sicherheitshacks.
Mit systemd können Sie den Zugriff auf Geräte für jeden Dienst einzeln steuern:

...
[Service]
ExecStart=...
DeviceAllow=/dev/null rw
...

Dadurch wird der Zugriff auf /dev/null und nur auf diesen Geräteknoten beschränkt und der Zugriff auf alle anderen Geräteknoten gesperrt.
Die Funktion wird auf dem cgroup-Controller des Geräts implementiert.

systemd Andere Optionen
Neben den oben genannten benutzerfreundlichen Optionen stehen eine Reihe weiterer sicherheitsrelevanter Optionen zur Verfügung.
Sie erfordern jedoch normalerweise ein wenig Vorbereitung im Dienst selbst und sind daher wahrscheinlich in erster Linie für Upstream-Entwickler nützlich.
Diese Optionen sind RootDirectory= (um chroot()-Umgebungen für einen Dienst einzurichten) sAchtung:
Einige Dienste reagieren möglicherweise verwirrt, wenn bestimmte Funktionen für sie nicht verfügbar sind.
Wenn Sie also die richtigen Fähigkeiten bestimmen, die Sie behalten möchten, müssen Sie dies sorgfältig tun, und es könnte eine gute Idee sein, mit den Upstream-Betreuern zu sprechen, da sie am besten wissen sollten, welche Operationen ein Dienst möglicherweise erfolgreich ausführen muss.