In dieser Artikelserie werden einige meiner Lieblingsfunktionen von Red Hat Enterprise Linux (RHEL) 8 untersucht, die durch systemd aktiviert werden . Daher setzt diese Reihe Vertrautheit mit den Grundkonzepten von systemd voraus . Wenn Sie eine gute Einführung benötigen, finden Sie im Red Hat Kundenportal sowie auf der Projektwebsite eine Fülle von Produktdokumentationen. Alternativ gibt es eine Reihe von Präsentationen auf YouTube, um Sie auf den neuesten Stand zu bringen, bevor Sie fortfahren.
Systemd bietet eine beträchtliche Anzahl von Sicherheitsfunktionen, mit denen Dienste und Anwendungen voneinander sowie vom zugrunde liegenden Betriebssystem isoliert werden können. In vielen Fällen systemd bietet einfachen Zugriff auf dieselben Mechanismen, die vom Linux-Kernel bereitgestellt werden und auch zum Erstellen von Isolation für Linux-Container verwendet werden. Die Möglichkeit, herkömmliche Anwendungen und Dienste containerartig zu isolieren, ist leistungsstark, da es jetzt einfach ist, die Sicherheit und Isolierung von Workloads zu verbessern, ohne die betrieblichen Auswirkungen, die Container erfordern. Es ist erwähnenswert, dass die durch die Einführung von Containern inspirierten betrieblichen und organisatorischen Veränderungen in der Tat gesund und lohnenswert sind. Aber selbst in den Container-versiertesten Unternehmen gibt es eine große Anzahl traditioneller Linux-Bereitstellungen, bei denen Sicherheit oberste Priorität hat. Wie wir sehen werden, können die Workloads auf diesen Systemen von nur wenigen Änderungen an den entsprechenden Unit-Dateien profitieren.
Sicherheitsoptionen, die Red Hat Enterprise Linux 7 und 8 gemeinsam sind
Die Mehrheit der unten untersuchten Optionen akzeptiert ein binäres true oder false Konfiguration, die sie einfach zu aktivieren macht. Es gibt einige, die zusätzliche Optionen enthalten, und die wichtigsten davon werden ebenfalls angezeigt. Weitere Einzelheiten finden Sie in der vollständigen Dokumentation und den Manpages. Wenn Sie sich nicht für das Wesentliche dieser Optionen interessieren, können Sie gerne zum nächsten Abschnitt springen, in dem wir diese Optionen für kohärentere Beispiele zusammenstellen:
| Option | Beschreibung |
|---|---|
PrivateTmp=yes | Erzeugt einen Dateisystem-Namespace unter /tmp/systemd-private-*-[unit name]-*/tmp statt eines gemeinsam genutzten /tmp oder /var/tmp . Viele der Unit-Dateien, die mit Red Hat Enterprise Linux geliefert werden, enthalten diese Einstellung und sie entfernt eine ganze Klasse von Schwachstellen rund um die Vorhersage und Ersetzung von Dateien, die in /tmp verwendet werden . |
PrivateNetwork= | Stellt einen Netzwerk-Namespace für den Dienst bereit, wobei nur eine Loopback-Schnittstelle verfügbar ist. Eine großartige Option für Anwendungen, die keine externe Netzwerkkommunikation erfordern. |
SELinuxContext= | Führt die Anwendung in einem bestimmten Kontext aus. Diese Option ist eine gute Idee, um zu definieren, wann eine Richtlinie für Anwendungen verfügbar ist, die außerhalb von RHEL ausgeliefert werden. Eine gute SELinux-Grundierung finden Sie hier. |
NoNewPrivileges= | Verhindert, dass der Dienst und zugehörige untergeordnete Prozesse Privilegien eskalieren. |
ProtectSystem=yes | Erzeugt /usr und /boot schreibgeschützt für die Anwendung. Setzen Sie diese Option auf full macht auch /etc schreibgeschützt. In Red Hat Enterprise Linux 8 gibt es eine zusätzliche Option namens strict das macht auch /dev , /proc , und /sys schreibgeschützt. |
ProtectHome=yes | Erzeugt /home , /root , und /run/user leer erscheinen. Eine zusätzliche Option ist read-only , die genau das tut, was sie sagt. Ebenfalls neu in RHEL 8, tmpfs wird an diesen Stellen ein beschreibbares, flüchtiges Dateisystem überlagern. Da diese Verzeichnisse zum Speichern von SSH-Schlüsseln und anderen potenziell vertraulichen Informationen verwendet werden, ist es eine gute Idee, Anwendungen den Zugriff zu verbieten. |
ProtectDevices=yes | Erzeugt einen privaten /dev Namespace, der nur Pseudogeräte wie /dev/null enthält und /dev/random , die keinen Zugriff auf tatsächliche Hardware gewähren. Es deaktiviert auch CAP_MKNOD sodass keine neuen Geräteknoten erstellt werden können. |
CapabilityBoundingSet= | Akzeptiert eine Whitelist und Blacklist mit privilegierten Fähigkeiten für die Einheit. Linux-Funktionen unterteilen den Root-Benutzerzugriff auf das System, sodass privilegierter Zugriff besser lokalisiert werden kann. Das klassische Beispiel ist für NTP oder chrony um die Systemuhr konfigurieren zu können, aber keine anderen privilegierten Aktionen auszuführen. Weitere Einzelheiten finden Sie in der Manpage Capabilities (7). |
|
| Verhält sich ähnlich wie ProtectSystem , aber alle drei dieser Optionen ermöglichen eine feinkörnige Kontrolle des Dateisystemzugriffs. |
Neue Sicherheitsoptionen in Red Hat Enterprise Linux 8
Die neuen systemd-Sicherheitsoptionen, die in Red Hat Enterprise Linux 8 verfügbar sind, sind:
| Option | Beschreibung |
|---|---|
ProtectKernelTunables=yes | Deaktiviert die Änderung von /proc und /sys . |
ProtectKernelModules=yes | Verbietet das Laden oder Entladen von Modulen und maskiert /usr/lib/modules aus der Anwendung. |
ProtectControlGroups=yes | Deaktiviert den Schreibzugriff auf /sys/fs/cgroup/ . |
RestrictNamespaces= | Beschränken Sie alle oder eine Teilmenge von Namespaces auf den Dienst. Akzeptiert cgroup , ipc , net , mnt , pid , user , und uts . |
AssertSecurity= | Erfordert eine Reihe von Anforderungen, die vom System erfüllt werden müssen, damit der Dienst gestartet werden kann. Wenn die aufgelisteten Funktionen nicht verfügbar sind, kann der Dienst nicht ausgeführt werden und das Ereignis wird protokolliert. Optionen wie selinux und uefi-secureboot sind für viele Umgebungen nützlich. |
MemoryDenyWriteExecute= | Deaktiviert Speicherzuordnung, die gleichzeitig beschreibbar und ausführbar ist. |
RestrictRealtime=yes | Verbietet Echtzeitplanung. |
PrivateMounts=yes | Bewirkt, dass der Dienst in einem privaten Mount-Namespace ausgeführt wird. |
DynamicUser=yes | Erzeugt effektiv einen vorübergehenden Benutzer für die Anwendung. Diese Option rechtfertigt wahrscheinlich einen eigenen Beitrag, um sie zu untersuchen, aber kurz das systemd Die Implementierung ist brillant, weil sie dynamisch (wie der Name schon sagt) eine UID und GID erstellt, indem sie ein nss einfügt Modul, das den Benutzer spontan "erstellt". Diese Benutzer existieren einfach nicht, wenn der Dienst nicht ausgeführt wird. Diese Funktion ist am nützlichsten für zustandslose Anwendungen, aber Verzeichnisse können zum Schreiben zugeordnet werden. |
SystemCallFilter= | Ermöglicht es Ihnen, einzelne Systemaufrufe auf die Whitelist und Blacklist zu setzen oder die benutzerfreundlichen Aufrufgruppen von systemd zu verwenden bietet. Wenn Sie mit seccomp vertraut sind Filtern mit Containern bietet diese Option genau dasselbe. Im Allgemeinen werden die meisten Benutzer den @system-service finden Filterwert, der die relevanten Systemaufrufe ermöglicht, die von den meisten Diensten benötigt werden. Benutzer können die Liste der Gruppen und verfügbaren Systemaufrufe anzeigen, indem sie systemd-analyze syscall-filter ausführen . |
[Möchten Sie Red Hat Enterprise Linux ausprobieren? Jetzt kostenlos herunterladen.]
Ein Beispiel
Wenn Sie es bis hierher geschafft haben, denken Sie vielleicht:„Okay, das scheint wirklich mächtig zu sein, aber das ist eine Menge, an die man sich erinnern muss.“ Glücklicherweise haben wir ab Red Hat Enterprise Linux 8.1 einen Befehl hinzugefügt, der es viel einfacher macht, auf diese Optionen zu verweisen und deren Status zu überprüfen:
systemd-analyze security [unit]
Dieser Befehl erstellt einen schnellen Schnappschuss darüber, wie das System systemd nutzt ’s Sandboxing und kann auch die individuellen Einstellungen pro Einheit einsehen. Dieses Design macht es einfach, die verfügbaren Optionen zu identifizieren und ihre Verwendung auf granularer Ebene anzuzeigen.
Hier ist die Ausgabe des standardmäßigen httpd.service Einheit:
Diese Ausgabe von systemd-analyze security zeigt den Namen, eine praktische Beschreibung und eine Expositionsbewertung, die den Verbrauch der verfügbaren Sicherheitseinstellungen pro Dienst zeigt und eine gewichtete Expositionsbewertung aus der Isolation des Dienstes generiert. Es ist erwähnenswert, dass dieses Tool nicht dazu gedacht ist, eine ganzheitliche Sicht oder Meinung zur Sicherheit für den Code oder die Anwendung zu bieten, die auf dem System ausgeführt wird. Nur weil httpd.service kommt als UNSAFE zurück bei einer Standardinstallation bedeutet nicht, dass der Dienst unsicher ist.
Nachdem wir nun wissen, wie Einheiten abgefragt werden und welche Steuerelemente verwendet werden, schauen wir uns an, wie diese auf einen einfachen Webserver angewendet werden. Dieses allgemeine Beispiel dient als einfacher Ausgangspunkt für andere Dienste und Anwendungen.
Schalten Sie die Sicherheitsoptionen ein
Erstellen Sie zunächst ein Systemd-Drop-In, um die Sicherheitsoptionen hinzuzufügen. Führen Sie für Red Hat Enterprise Linux 8 Folgendes aus:
# systemctl edit httpd
Oder erstellen Sie manuell /etc/systemd/system/httpd.service.d/security.conf, wenn Sie dies vorziehen .
Unabhängig davon, wie Sie auf die Datei zugegriffen haben, fügen Sie jetzt Folgendes hinzu:
[Service]
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
NoNewPrivileges=yes
PrivateTmp=yes
Für Red Hat Enterprise Linux 7 können wir eine ähnliche Vorlage verwenden:
[Service]
ProtectSystem=full
ProtectHome=yes
PrivateDevices=yes
NoNewPrivileges=yes
PrivateTmp=yes
Nachdem Sie die Datei gespeichert und den Dienst neu gestartet haben, wird die Datei httpd Der Dienst wird erheblich vom Rest des Betriebssystems isoliert. Wenn der Dienst jemals beeinträchtigt wird, wird das Potenzial für einen Ausbruch und daraus resultierende Schäden drastisch reduziert.
Die obigen Beispiele sind ein guter Ausgangspunkt für das Sperren von Diensten, Anwendungen und Einheiten, die auf Ihrem System ausgeführt werden. Sie sollten diese natürlich testen, um sicherzustellen, dass sie für Ihren Anwendungsfall geeignet sind, bevor Sie sie auf Ihre gesamte Flotte ausrollen. Wenn wir beispielsweise Inhalte aus den Home-Verzeichnissen der Benutzer bereitstellen wollten, würden wir ProtectHome=yes nicht einschließen , verwenden Sie stattdessen ProtectHome=read-only . Erwähnenswert ist auch, dass es nicht schadet, die neueren Optionen, die in RHEL 8 hinzugefügt wurden, in eine Unit-Datei aufzunehmen, die in RHEL 7 ausgeführt wird. Eine Benachrichtigung wird ausgegeben und die Option wird ignoriert.
Siehe die Ergebnisse
Wir können jetzt die verwendeten Optionen anzeigen, indem wir systemd-analyze httpd ausführen :
Sie können sehen, dass jetzt eine Reihe von Optionen auf dem Webserver erzwungen werden. Die Bewertung hat sich auch von UNSAFE geändert auf MEDIUM . Obwohl es durchaus möglich ist, mehr Optionen zu aktivieren und den Dienst weiter zu sperren, würden wir von dem Ziel abweichen, ein praktisches Beispiel zu liefern, das erfolgreich auf viele Dienste und Anwendungen in der realen Welt angewendet werden kann. Nie zuvor war es so einfach, den Zugriff eines herkömmlichen Dienstes auf das zugrunde liegende Betriebssystem zu beschränken.
Schlussfolgerung
Für Entwickler, die daran interessiert sind, Ihre eigene Software zu sichern, können die relevanten Sicherheitsoptionen einfach zu den Unit-Dateien hinzugefügt werden, die Ihrer Anwendung beiliegen. Red Hat ermutigt Entwickler nachdrücklich, standardmäßig so viel Sicherheit wie möglich „einzubacken“, und dies ist eine der einfachsten Möglichkeiten, dieses Ziel zu erreichen.
Für diejenigen, die sich fragen, ob die hier gezeigten Sicherheitsfunktionen mit SELinux redundant sind, gibt es Funktionsüberschneidungen, aber sie sind weitgehend unabhängig. Diese Einstellungen gelten unabhängig davon, ob SELinux verwendet wird oder nicht. Diese Funktion ist von großem Wert, wenn SELinux aufgrund von Richtlinien oder Anwendungsanforderungen für bestimmte Systeme keine praktikable Option darstellt. In einer idealen Welt würden diese with verwendet werden SELinux als Teil eines mehrschichtigen Sicherheitsansatzes.
Ich hoffe, es hat Ihnen Spaß gemacht, zu erfahren, wie einfach es ist, Workloads, die auf Red Hat Enterprise Linux 8 installiert sind, mit systemd zu isolieren und in eine Sandbox zu versetzen . Machen Sie sich jetzt auf den Weg und wenden Sie dieses Wissen gegebenenfalls auf Ihre gesamte(n) Umgebung(en) an. Im nächsten Artikel dieser Serie werden wir uns mit der Verwendung von Linux-Kontrollgruppen, auch bekannt als cgroups, befassen , über systemd zum Schutz wertvoller Systemressourcen und zur Lösung des „Noisy Neighbor“-Problems.