Was ist SELinux?

Labels und Kontexte statt Benutzerrechte

Jedes Objekt im System trägt einen Kontext aus vier Teilen: SELinux-Benutzer, Rolle, Typ und Sicherheitsstufe. Sichtbar wird er mit ls -Z für Dateien und ps -Z für Prozesse:

$ ls -Z /var/www/html/index.html
system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

$ ps -eZ | grep httpd
system_u:system_r:httpd_t:s0    1234 ?  00:00:01 httpd

Entscheidend ist im Alltag der Typ, die dritte Stelle. Der Webserver läuft als httpd_t und darf laut Policy auf Dateien vom Typ httpd_sys_content_t zugreifen, auf den Kontext der Benutzerverzeichnisse dagegen nicht. Ob der Dateieigentümer den Zugriff erlauben würde, spielt keine Rolle. Dieses Prinzip heißt Type Enforcement und trägt fast die gesamte Policy der gängigen Distributionen.

Daraus folgt der Fehler, den fast jeder einmal macht: Eine Datei wird mit mv aus dem Home-Verzeichnis nach /var/www verschoben und behält dabei ihren alten Kontext, während cp den Kontext des Zielverzeichnisses erbt. Die Rechte sehen richtig aus, der Zugriff scheitert trotzdem. restorecon setzt den Kontext auf den Wert zurück, den die Policy für diesen Pfad vorsieht.

Die drei Modi

Im Modus enforcing werden Verstöße blockiert und protokolliert, in permissive nur protokolliert, und disabled schaltet den Mechanismus ganz ab. getenforce zeigt den aktuellen Modus, setenforce wechselt bis zum nächsten Neustart zwischen enforcing und permissive. Für die Fehlersuche ist permissive das richtige Werkzeug, weil du in einem Durchlauf alle Blockaden siehst statt immer nur die erste.

Zwischen permissive und disabled liegt ein Unterschied, der oft übersehen wird. Läuft ein System längere Zeit mit abgeschaltetem SELinux, bekommen neue Dateien keine Labels mehr. Beim Wiedereinschalten passt dann nichts mehr zusammen, und es braucht ein vollständiges Neulabeln des Dateisystems mit Neustart. Ab RHEL 9 reicht der Eintrag in /etc/selinux/config zum Abschalten ohnehin nicht mehr, dafür ist der Kernel-Parameter selinux=0 nötig, von dem Red Hat im Produktivbetrieb ausdrücklich abrät.

Kontexte, Ports und Booleans anpassen

Für fast alle Sonderfälle sieht SELinux einen Verwaltungsweg vor, ohne dass du eigene Regeln schreibst. Die drei häufigsten Fälle sind ein Webverzeichnis außerhalb von /var/www, ein Dienst auf einem ungewöhnlichen Port und ein Webserver, der selbst Verbindungen zu einer Datenbank oder API aufbauen soll:

# Kontext für ein eigenes Verzeichnis dauerhaft festlegen und anwenden
semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
restorecon -Rv /srv/web

# zusätzlichen Port für den Webserver freigeben
semanage port -a -t http_port_t -p tcp 8081

# Boolean dauerhaft setzen
setsebool -P httpd_can_network_connect on

getsebool -a listet alle Booleans. Bleibt trotzdem eine Lücke, erzeugt audit2allow aus den protokollierten Verweigerungen ein Policy-Modul. Das ist bequem und genau deshalb heikel: Wer die Ausgabe ungeprüft einspielt, erlaubt unter Umständen genau den Zugriff, den ein Angriff gerade versucht hat. Lies die Regel, bevor du sie lädst, und beschränke sie auf den Typ, um den es geht.

Denials lesen

Verweigerungen landen als AVC-Meldungen (Access Vector Cache) im Audit-Log. ausearch -m avc -ts recent holt die letzten heraus, und sealert aus dem Paket setroubleshoot übersetzt sie in eine Erklärung samt Vorschlag. Wer die Meldung selbst liest, achtet auf scontext, tcontext und tclass: Welcher Prozess wollte auf welches Objekt welcher Art zugreifen?

Nicht jede Blockade taucht auf. Für bekannte, unkritische Fälle enthält die Policy dontaudit-Regeln, die die Protokollierung unterdrücken. Wenn ein Problem unerklärlich wirkt, schaltet semodule -DB diese Unterdrückung vorübergehend ab, semodule -B stellt sie wieder her.