Was ist SELinux und wie kann es die Sicherheit auf Linux-Servern verbessern?

Wenn die meisten Systemadministratoren über die Härtung eines Linux-Servers nachdenken, konzentrieren sie sich auf die Grundlagen: Pakete aktuell halten, Firewall-Regeln konfigurieren und SSH-Zugriff einschränken. Dies sind alles gültige und notwendige Schritte — aber sie lassen eine erhebliche Lücke. Einer der leistungsstärksten und am häufigsten unternutzten Sicherheitsmechanismen unter Linux ist SELinux (Security-Enhanced Linux), ein Kernel-Level-Framework für obligatorische Zugriffskontrolle, das Bedrohungen eindämmen soll, bevor sie sich zu vollständigen Systemkompromittierungen entwickeln.

Egal ob Sie eine VPS Hosting-Umgebung, eine hochfrequente Anwendung auf Dedicated Servers oder eine Multi-Tenant-Shared Web Hosting-Plattform betreiben — SELinux kann die entscheidende Schicht sein, die einen ernsthaften Verstoß in einen eingedämmten, wiederherstellbaren Vorfall umwandelt.

Was ist SELinux?

SELinux ist ein Linux-Kernel-Sicherheitsmodul, das Mandatory Access Control (MAC) implementiert. Um zu verstehen, warum dies wichtig ist, müssen Sie zunächst verstehen, was es ersetzt — oder besser gesagt, was es ergänzt.

Das traditionelle Linux-Sicherheitsmodell basiert auf Discretionary Access Control (DAC). Unter DAC werden Zugriffsgenehmigungen durch Dateieigentümerschaft und Gruppenmitgliedschaft bestimmt. Der Root-Benutzer hat unbegrenzte Macht über das gesamte System. Wenn ein Angreifer Root erhält, erhält er alles.

Unter SELinux’ MAC-Modell wird der Zugriff durch systemweite Sicherheitsrichtlinien geregelt, die auf Kernel-Ebene durchgesetzt werden. Entscheidend ist, dass selbst der Root-Benutzer diesen Einschränkungen unterliegt. Ein Prozess, der als Root läuft, kann keine Aktionen ausführen, die seine SELinux-Richtlinie nicht ausdrücklich erlaubt.

SELinux wurde ursprünglich von der National Security Agency (NSA) in Zusammenarbeit mit Red Hat entwickelt und in den frühen 2000er Jahren in den Mainline-Linux-Kernel integriert. Heute ist es eine Standardkomponente von Enterprise-Grade-Linux-Distributionen wie RHEL, CentOS, Fedora, AlmaLinux und Rocky Linux.

Wo traditionelle Linux-Sicherheit zu kurz kommt

Das klassische UNIX-Berechtigungsmodell hat Linux Jahrzehnte lang gut gedient, aber es weist strukturelle Schwächen auf, die moderne Angreifer routinemäßig ausnutzen:

• Root ist allmächtig. Jeder Exploit, der erfolgreich zu Root eskaliert, gibt dem Angreifer uneingeschränkten Zugriff auf das gesamte System — Dateien, Datenbanken, Netzwerk-Sockets und alles.
• Service-Kompromittierung bedeutet Systemkompromittierung. Ein anfälliges Apache-Modul, ein schlecht codiertes PHP-Skript oder eine falsch konfigurierte Anwendung können verwendet werden, um sich über den gesamten Server auszubreiten.
• Moderne Angriffsvektoren umgehen DAC vollständig. Web-Shells, Privilege-Escalation-Exploits, Container-Escapes und Supply-Chain-Angriffe sind so konzipiert, dass sie innerhalb der Grenzen traditioneller Berechtigungen funktionieren und dennoch katastrophale Schäden verursachen.

Realistisches Angriffszenario

Betrachten Sie eine häufige CMS-Anfälligkeit, die es einem Angreifer ermöglicht, eine Web-Shell hochzuladen und auszuführen.

Ohne SELinux: Der Angreifer liest config.php, extrahiert Datenbankzugangsdaten, dumpt die Datenbank, bewegt sich lateral zu anderen gehosteten Sites und erreicht möglicherweise vollständigen Root-Zugriff. Der gesamte Stack wird von einem einzigen Einstiegspunkt aus kompromittiert.

Mit SELinux: Der Apache-Webserver-Prozess läuft in der httpd_t-Domäne. Die Richtlinie beschränkt streng, worauf httpd_t zugreifen kann. Die Web-Shell kann keine Dateien außerhalb der designierten Content-Domäne lesen, kann keine nicht autorisierten Netzwerkverbindungen öffnen und kann System-Konfigurationsdateien nicht anfassen. Der Verstoß wird auf der Anwendungsebene eingedämmt.

Dies ist die Kernwertproposition von SELinux: Schadenseindämmung durch Prozesseingrenzung.

Wie SELinux funktioniert: Sicherheitskontexte und Richtliniendurchsetzung

SELinux funktioniert, indem jedem Prozess, jeder Datei, jedem Port und jedem Netzwerk-Socket auf dem System ein Sicherheitskontext (Label) zugewiesen wird. Richtlinien definieren dann, welche Kontexte miteinander interagieren dürfen. Der Kernel erzwingt diese Regeln bei jedem Zugriffversuch.

Ein konkretes Beispiel

Die SELinux-Richtlinie erlaubt httpd_t, Dateien mit dem Label httpd_sys_content_t zu lesen. Sie erlaubt nicht httpd_t, shadow_t zu lesen.

Wenn Apache — ob legitim oder aufgrund von Ausnutzung — versucht, /etc/shadow zu lesen, verweigert der Kernel die Anfrage und schreibt einen detaillierten Verstoßeintrag in /var/log/audit/audit.log. Der Angriff wird blockiert und dokumentiert gleichzeitig.

SELinux-Betriebsmodi

SELinux funktioniert in drei verschiedenen Modi:

Überprüfung und Festlegung des aktuellen Modus

# Check current SELinux status
getenforce
sestatus

# Temporarily switch to permissive mode (no reboot required)
setenforce 0

# Switch back to enforcing mode
setenforce 1

Um den Modus dauerhaft zu ändern, bearbeiten Sie /etc/selinux/config und setzen Sie SELINUX=enforcing (oder permissive), dann starten Sie neu.

> Best Practice: Stellen Sie neue Server zunächst im Permissive-Modus bereit. Überprüfen Sie die Audit-Protokolle, identifizieren Sie alle legitimen Prozesse, die gekennzeichnet werden, optimieren Sie Ihre Richtlinien und wechseln Sie dann zum Enforcing-Modus für die Produktion. Dieser Ansatz verhindert Betriebsstörungen und stellt sicher, dass Ihre Richtlinien korrekt sind.

SELinux-Richtlinientypen

SELinux wird mit mehreren Richtlinientypen geliefert, die für verschiedene Umgebungen geeignet sind:

Targeted Policy (Standard und empfohlen)

Wendet MAC-Einschränkungen nur auf netzwerkfähige Services wie Apache, Nginx, Postfix, Dovecot und DNS an. Alle anderen Prozesse laufen in einer uneingeschränkten Domäne. Dies ist das beste Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit für die überwiegende Mehrheit der VPS- und Dedicated-Server-Workloads.

Strict Policy

Wendet MAC auf alle Prozesse auf dem System an, einschließlich Benutzersitzungen. Bietet maximale Sicherheit, erfordert aber erheblich mehr Richtlinienverwaltung und operative Expertise.

MLS/MCS (Multi-Level Security / Multi-Category Security)

Fortgeschrittene Richtlinientypen für Regierungs-, klassifizierte oder hochgradig regulierte Umgebungen, in denen Daten gleichzeitig über mehrere Sensitivitätsstufen isoliert werden müssen.

Für die meisten Produktions-Server-Bereitstellungen ist Targeted Policy die richtige Wahl.

Warum SELinux für Hosting, DevOps und Compliance wichtig ist

SELinux bietet greifbare Sicherheitsvorteile in einer Vielzahl von Betriebskontexten:

Prozesseisolation

Jeder eingeschränkte Service funktioniert innerhalb seiner eigenen Sicherheitsdomäne. Die Kompromittierung eines Service — sagen wir, einer Webanwendung — gewährt keinen Zugriff auf andere Services, die auf demselben Host laufen. Dies ist besonders wertvoll in Multi-Anwendungs-Server-Umgebungen.

Durchsetzung des Prinzips der geringsten Berechtigung

SELinux erzwingt das Prinzip der geringsten Berechtigung auf Kernel-Ebene. Prozesse können nur auf die Ressourcen zugreifen, die sie explizit benötigen. Selbst wenn ein Angreifer Root innerhalb eines eingeschränkten Prozesses erhält, können sie die durch die Richtlinie definierten Berechtigungen nicht überschreiten.

Audit-Trails und Forensik

Jeder verweigerte Zugriffversuch wird in /var/log/audit/audit.log mit vollständigem Kontext protokolliert: der beteiligte Prozess, die Ressource, auf die er zugreifen versuchte, die Sicherheitskontexte beider und ein Zeitstempel. Dies macht die Forensik nach Vorfällen dramatisch effektiver.

Container-Sicherheit

SELinux verhindert, dass Docker- und Podman-Container ihre Grenzen verlassen und auf Host-Ressourcen zugreifen. Dies ist eine kritische Verteidigungsschicht für containerisierte Workloads, bei denen Container-Escape-Anfälligkeit eine bekannte Angriffklasse ist.

Einhaltung von Vorschriften

SELinux ist eine erforderliche Kontrolle in mehreren Compliance-Frameworks, einschließlich PCI DSS, HIPAA und militärischen/behördlichen Sicherheitsstandards. Die Ausführung von SELinux im Enforcing-Modus mit einer dokumentierten Richtlinie ist oft eine Voraussetzung für das Bestehen von Sicherheitsprüfungen in regulierten Branchen.

Wesentliche SELinux-Befehle für Systemadministratoren

Hier sind die am häufigsten verwendeten Befehle für die Verwaltung von SELinux im täglichen Betrieb:

SELinux-Status überprüfen

getenforce
sestatus

Dateikontexte nach dem Verschieben von Web-Dateien wiederherstellen

Wenn Dateien verschoben statt kopiert werden, können sie falsche Sicherheitslabels behalten. Verwenden Sie restorecon um dies zu beheben:

restorecon -Rv /var/www/html

Dateisicherheitslabels auflisten

ls -Z /var/www/html

Web-Service-Ausgangsverbindungen zulassen (z. B. für API-Aufrufe oder Proxying)

setsebool -P httpd_can_network_connect 1

Apache die Verbindung zu einer Datenbank erlauben

setsebool -P httpd_can_network_connect_db 1

Kürzlich verweigerte Aktionen im Audit-Protokoll überprüfen

ausearch -m avc -ts recent

Ein benutzerdefiniertes Richtlinienmodul aus Audit-Verweigerungen generieren

audit2allow -a -M my_custom_policy
semodule -i my_custom_policy.pp

> Wichtig: Untersuchen Sie immer Audit-Verweigerungen, bevor Sie Zulassungsregeln erstellen. audit2allow ist ein leistungsstarkes Tool, aber das blinde Zulassen aller Verweigerungen besiegt den Zweck von SELinux. Verstehen Sie, was jede Regel erlaubt, bevor Sie sie anwenden.

Häufige SELinux-Fallstricke und wie man sie vermeidet

SELinux deaktivieren statt es zu reparieren. Der häufigste Fehler, den Administratoren machen, ist die dauerhafte Deaktivierung von SELinux, wenn sie auf eine Verweigerung stoßen. Dies entfernt eine ganze Schutzschicht. Verwenden Sie stattdessen audit2allow und setsebool um spezifische Probleme zu beheben, während SELinux aktiv bleibt.

Falsche Dateilabels nach manuellen Bereitstellungen. Wenn Sie Anwendungsdateien bereitstellen, indem Sie sie von einem nicht standardmäßigen Ort kopieren, können sie falsche Labels erben. Führen Sie immer restorecon nach manuellen Dateivorgängen in Web-Roots und Anwendungsverzeichnissen aus.

Protokolle im Permissive-Modus nicht überprüfen. Das Überspringen der Permissive-Phase und das direkte Wechseln zum Enforcing auf einem Produktionsserver ist ein Rezept für unerwartete Ausfallzeiten. Validieren Sie Richtlinien immer gegen echten Traffic, bevor Sie sie erzwingen.

SELinux und AlexHost: Produktionsreife Sicherheit von Grund auf

AlexHost-Server, auf denen Enterprise-Linux-Distributionen ausgeführt werden (AlmaLinux, Rocky Linux, CentOS), werden mit SELinux ab Werk bereitgestellt