Version vom 10. Januar 2023, 13:58 Uhr

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.

Isolieren von Diensten vom Netzwerk

Eine sehr einfache, aber leistungsstarke Konfigurationsoption, die Sie in systemd-Dienstdefinitionen verwenden können, ist PrivateNetwork=:

...
[Service]
ExecStart=...
PrivateNetwork=yes
...

Mit diesem einfachen Schalter wird ein Dienst und alle Prozesse, aus denen er besteht, vollständig von jeglicher Art der Vernetzung getrennt.
Netzwerkschnittstellen sind für die Prozesse nicht mehr verfügbar, die einzige, die sie sehen, ist das Loopback-Gerät "lo", aber es ist vom echten Host-Loopback isoliert.
Dies ist ein sehr leistungsfähiger Schutz vor Netzwerkangriffen.

Vorbehalt: Einige Dienste erfordern, dass das Netzwerk betriebsbereit ist. Natürlich würde niemand in Betracht ziehen, PrivateNetwork=yes auf einem netzwerkorientierten Dienst wie Apache zu verwenden.
Aber auch für nicht netzwerkorientierte Dienste kann Netzwerkunterstützung notwendig und nicht immer selbstverständlich sein.
Beispiel: Wenn das lokale System für eine LDAP-basierte Benutzerdatenbank konfiguriert ist, kann das Suchen von Glibc-Namen mit Aufrufen wie getpwnam() zu einem Netzwerkzugriff führen. Das heißt, selbst in diesen Fällen ist es meistens in Ordnung, PrivateNetwork=yes zu verwenden, da Benutzer-IDs von Systemdienstbenutzern auch ohne Netzwerk auflösbar sein müssen.
Das heißt, solange die einzigen Benutzer-IDs, die Ihr Dienst auflösen muss, unter der magischen Grenze von 1000 liegen, sollte die Verwendung von PrivateNetwork=yes in Ordnung sein.

Intern verwendet dieses Feature Netzwerknamensräume des Kernels.
Wenn aktiviert, wird ein neuer Netzwerk-Namespace geöffnet und nur das Loopback-Gerät darin konfiguriert.

Dienst-Privat /tmp Ein weiterer sehr einfacher, aber leistungsfähiger Konfigurationsschalter ist PrivateTmp=:

... [Service] ExecStart=... PrivateTmp=ja ... Wenn diese Option aktiviert ist, stellt sie sicher, dass das /tmp-Verzeichnis, das der Dienst sieht, privat und vom /tmp des Hostsystems isoliert ist. /tmp war traditionell ein gemeinsam genutzter Bereich für alle lokalen Dienste und Benutzer. Im Laufe der Jahre war es eine Hauptquelle von Sicherheitsproblemen für eine Vielzahl von Diensten. Symlink-Angriffe und DoS-Schwachstellen aufgrund erratbarer temporärer /tmp-Dateien sind häufig. Indem das /tmp des Dienstes vom Rest des Hosts isoliert wird, werden solche Schwachstellen hinfällig.

Für Fedora 17 wurde ein Feature akzeptiert, um diese Option für eine große Anzahl von Diensten zu aktivieren.

Achtung: Einige Dienste missbrauchen /tmp tatsächlich als Speicherort für IPC-Sockets und andere Kommunikationsprimitive, obwohl dies fast immer eine Schwachstelle ist (einfach, weil Sie erratende Namen benötigen, wenn Sie es für die Kommunikation verwenden, und erratbare Namen Ihren Code anfällig für DoS machen und Symlink-Angriffe) und /run ist der viel sicherere Ersatz dafür, einfach weil es kein Ort ist, auf den nichtprivilegierte Prozesse schreiben können. Zum Beispiel platziert X11 seine Kommunikations-Sockets unterhalb von /tmp (was eigentlich sicher ist – wenn auch immer noch nicht ideal – in dieser Ausnahme, da es dies in einem sicheren Unterverzeichnis tut, das beim frühen Booten erstellt wird). Dienste, die über solche kommunizieren müssen Kommunikationsprimitive in /tmp sind keine Kandidaten für PrivateTmp=. Glücklicherweise sind heutzutage nur noch sehr wenige Dienste übrig, die /tmp so missbrauchen.

Intern nutzt diese Funktion Dateisystem-Namensräume des Kernels. Wenn aktiviert, wird ein neuer Dateisystem-Namensraum geöffnet, der den größten Teil der Hosthierarchie mit Ausnahme von /tmp erbt.

Verzeichnisse als schreibgeschützt oder für Dienste nicht zugänglich machen Mit den Optionen ReadOnlyDirectories= und InaccessibleDirectories= ist es möglich, die angegebenen Verzeichnisse zum Schreiben bzw. Schreiben unzugänglich zu machen. sowohl Lesen als auch Schreiben an den Dienst:

... [Service] ExecStart=... InaccessibleDirectories=/home ReadOnlyDirectories=/var ... Mit diesen beiden Konfigurationszeilen wird der gesamte Baum unterhalb von /home für den Dienst unzugänglich (d. h. das Verzeichnis erscheint leer und im Zugriffsmodus 000), und der Baum unterhalb von /var wird schreibgeschützt.

Vorbehalt: Beachten Sie, dass ReadOnlyDirectories= derzeit nicht rekursiv auf Submounts der angegebenen Verzeichnisse angewendet wird (d. h. Mounts unter /var im obigen Beispiel bleiben beschreibbar). Dies wird wahrscheinlich bald behoben.

Intern wird dies ebenfalls auf Basis von Dateisystem-Namensräumen implementiert.

Fähigkeiten von Diensten wegnehmen Eine weitere sehr mächtige Sicherheitsoption in systemd ist CapabilityBoundingSet=, die es ermöglicht, auf relativ feinkörnige Weise einzuschränken, welche Kernel-Fähigkeiten ein gestarteter Dienst behält:

... [Service] ExecStart=... CapabilityBoundingSet=CAP_CHOWN CAP_KILL ... Im obigen Beispiel werden nur die CAP_CHOWN- und CAP_KILL-Fähigkeiten vom Dienst beibehalten, und der Dienst und alle Prozesse, die er möglicherweise erstellt, haben keine Chance, jemals wiederIsolieren von Diensten vom Netzwerk Eine sehr einfache, aber leistungsstarke Konfigurationsoption, die Sie in systemd-Dienstdefinitionen verwenden können, ist PrivateNetwork=:

... [Service] ExecStart=... PrivateNetwork=ja ... Mit diesem einfachen Schalter wird ein Dienst und alle Prozesse, aus denen er besteht, vollständig von jeglicher Art der Vernetzung getrennt. Netzwerkschnittstellen sind für die Prozesse nicht mehr verfügbar, die einzige, die sie sehen, ist das Loopback-Gerät "lo", aber es ist vom echten Host-Loopback isoliert. Dies ist ein sehr leistungsfähiger Schutz vor Netzwerkangriffen.

Vorbehalt: Einige Dienste erfordern, dass das Netzwerk betriebsbereit ist. Natürlich würde niemand in Betracht ziehen, PrivateNetwork=yes auf einem netzwerkorientierten Dienst wie Apache zu verwenden. Aber auch für nicht netzwerkorientierte Dienste kann Netzwerkunterstützung notwendig und nicht immer selbstverständlich sein. Beispiel: Wenn das lokale System für eine LDAP-basierte Benutzerdatenbank konfiguriert ist, kann das Suchen von Glibc-Namen mit Aufrufen wie getpwnam() zu einem Netzwerkzugriff führen. Das heißt, selbst in diesen Fällen ist es meistens in Ordnung, PrivateNetwork=yes zu verwenden, da Benutzer-IDs von Systemdienstbenutzern auch ohne Netzwerk auflösbar sein müssen. Das heißt, solange die einzigen Benutzer-IDs, die Ihr Dienst auflösen muss, unter der magischen Grenze von 1000 liegen, sollte die Verwendung von PrivateNetwork=yes in Ordnung sein.

Intern verwendet dieses Feature Netzwerknamensräume des Kernels. Wenn aktiviert, wird ein neuer Netzwerk-Namespace geöffnet und nur das Loopback-Gerät darin konfiguriert.

Dienst-Privat /tmp Ein weiterer seIsolieren von Diensten vom Netzwerk Eine sehr einfache, aber leistungsstarke Konfigurationsoption, die Sie in systemd-Dienstdefinitionen verwenden können, ist PrivateNetwork=:

... [Service] ExecStart=... PrivateNetwork=ja ...Isolieren von Diensten vom Netzwerk Eine sehr einfache, aber leistungsstarke Konfigurationsoption, die Sie in systemd-Dienstdefinitionen verwenden können, ist PrivateNetwork=: