Security & Hardening

SELinux verstehen statt abschalten: Kontexte, Booleans und Troubleshooting

setenforce 0 ist keine Lösung, sondern die Wette darauf, dass niemand die Lücke findet. In den meisten Fällen fehlt schlicht der richtige Dateikontext, und der ist mit semanage und restorecon in wenigen Minuten gesetzt.

4 Kapitel mit allen Befehlen
Zwei Security-Fachleute prüfen ein Dashboard im Betriebsraum
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum SELinux so oft im Permissive-Modus endet

Auf RHEL, Rocky, AlmaLinux und Fedora läuft SELinux ab Werk im Enforcing-Modus, und das fällt meist erst auf, wenn ein Dienst auf einem nicht standardmäßigen Pfad liegt oder auf einem ungewohnten Port lauscht. Der Webserver soll aus /srv/web ausliefern, die Anwendung braucht eine ausgehende Netzwerkverbindung, der Reverse Proxy soll auf 8443 hören. In allen drei Fällen greift eine Policy-Regel, und der Dienst scheitert mit einer Meldung, die nach einem Rechteproblem aussieht, obwohl die klassischen Unix-Rechte korrekt gesetzt sind.

Die übliche Reaktion ist setenforce 0 oder SELINUX=disabled in /etc/selinux/config. Damit ist der Fehler weg und mit ihm eine komplette Schutzschicht. Genau diese Schicht hindert einen kompromittierten Dienst daran, außerhalb seiner eigenen Domain zu arbeiten, und deshalb verlangt auch der BSI-Grundschutz für Linux-Systeme, dass vorhandene Zugriffskontrollmechanismen mit den mitgelieferten Standardprofilen aktiviert bleiben. Ein dauerhaft deaktiviertes SELinux lässt sich im Audit kaum begründen.

Der zweite typische Fehler ist gut gemeint. Ein Denial wird gefunden, audit2allow -M erzeugt ein Modul, semodule -i lädt es, und der Dienst läuft wieder. Nach einem Jahr liegen ein Dutzend selbst gebauter Module auf dem System, von denen niemand mehr weiß, welche Regel sie enthalten. Oft wäre stattdessen ein einzelnes semanage fcontext plus restorecon oder ein gesetzter Boolean die richtige Antwort gewesen, weil das Problem nicht in der Policy lag, sondern im falschen Label.

Miniatur-Szene: Serverschrank in einer Schutzhülle, Vorhängeschlösser und ein Schild davor
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Vom AVC-Denial zur richtigen Maßnahme

  1. 01 Denial mit ausearch finden
  2. 02 Kontext von Prozess und Objekt prüfen
  3. 03 Falsches Label? semanage fcontext und restorecon
  4. 04 Vorgesehener Anwendungsfall? Boolean setzen
  5. 05 Abweichender Port? semanage port ergänzen
  6. 06 Erst dann eigenes Policy-Modul bauen
Was du mitnimmst

So arbeitest du sauber mit SELinux

SELinux wird beherrschbar, sobald du das Modell dahinter kennst: Jeder Prozess und jedes Objekt trägt ein Label, und die Policy entscheidet, welche Domain auf welchen Typ zugreifen darf. Alles Weitere ist Handwerk, das sich in einer festen Reihenfolge abarbeiten lässt.

Das Label-Modell lesen können

Mit ps -eZ, ls -Z und id -Z siehst du Kontexte in der Form user:role:type:level. Für die tägliche Arbeit zählt vor allem der Typ, also httpd_t für den Prozess und httpd_sys_content_t für die Daten. Wer diese Paarung im Kopf hat, erkennt die meisten Denials schon an der Meldung.

Denials gezielt auswerten

ausearch -m AVC -ts recent liefert die Rohdaten, sealert und journalctl geben Kontext dazu. Wichtig ist die Unterscheidung zwischen einem echten Policy-Problem und einem falsch gelabelten Objekt, denn nur im ersten Fall braucht es überhaupt eine eigene Regel.

Erst Kontext, dann Policy

Für abweichende Pfade ist semanage fcontext -a -t gefolgt von restorecon -Rv der saubere Weg, weil die Regel eine Neuinstallation und ein relabel überlebt. chcon setzt Labels nur flüchtig und eignet sich zum Testen, nicht für den Dauerbetrieb.

Booleans statt eigener Module

Viele Anforderungen sind in der Standard-Policy bereits vorgesehen und lassen sich mit getsebool -a und setsebool -P freischalten, etwa httpd_can_network_connect oder nfs_export_all_rw. Das erspart eigene Module und bleibt dokumentiert und nachvollziehbar.

Ports und Dateisysteme korrekt einbinden

Nicht standardmäßige Ports werden über semanage port -a -t bekannt gemacht, Netzwerk-Mounts über die passenden Mount-Optionen und Booleans. Damit fallen die meisten Denials weg, die sonst zu einem selbst gebauten Modul führen würden.

Eigene Policy-Module nur mit Prüfung

Wenn wirklich eine eigene Regel nötig ist, gehören audit2allow, .te-Quelle, checkmodule und semodule_package in einen versionierten Ablauf. Der generierte Vorschlag ist ein Entwurf und kein fertiges Modul, denn audit2allow schlägt regelmäßig weitreichendere Rechte vor als tatsächlich gebraucht werden.

Tutorial

Vom AVC-Denial zur passenden Regel

SELinux hat den Ruf, kompliziert zu sein. Tatsächlich sind über 90 Prozent aller Probleme im Alltag derselbe Fall: eine Datei am falschen Ort mit falschem Kontext. Dieser Teil zeigt dir das Modell dahinter und den Weg von der Fehlermeldung zur Lösung, ohne den Schutz abzuschalten.

01

Das Modell in fünf Minuten

SELinux vergibt jedem Prozess und jeder Datei ein Label. Eine Regel erlaubt dann, dass Prozesse mit Label A auf Dateien mit Label B zugreifen dürfen. Alles, was nicht ausdrücklich erlaubt ist, wird verweigert. Mehr ist es im Kern nicht.

Labels sichtbar machen
# Kontext von Dateien
ls -Z /var/www/html
# system_u:object_r:httpd_sys_content_t:s0

# Kontext von Prozessen
ps -eZ | grep httpd
# system_u:system_r:httpd_t:s0

# Kontext deiner eigenen Sitzung
id -Z

Der interessante Teil ist der dritte: der Typ. httpd_t ist die Domäne des Webservers, httpd_sys_content_t der Typ für Inhalte, die er lesen darf. Passt beides nicht zusammen, gibt es eine Verweigerung.

Die drei Modi

ModusVerhaltenWofür
Enforcingverweigert und protokolliertProduktivbetrieb, das Ziel
Permissiveerlaubt, protokolliert aber die VerweigerungFehlersuche und Einführung neuer Anwendungen
Disabledgar kein SELinuxkein sinnvoller Anwendungsfall auf einem Server
02

Der Weg von der Fehlermeldung zur Ursache

Ein Dienst startet nicht oder eine Datei bleibt unlesbar. Bevor du irgendetwas änderst, lies das Audit-Log. Es sagt dir fast immer direkt, was fehlt.

Verweigerungen finden
# Was wurde zuletzt verweigert?
sudo ausearch -m avc -ts recent

# Im Klartext, mit Lösungsvorschlag
sudo sealert -a /var/log/audit/audit.log

# Nur zu einem bestimmten Dienst
sudo ausearch -m avc -c httpd -ts today -i

setroubleshoot-server muss installiert sein, damit sealert zur Verfügung steht. Es übersetzt die kryptische AVC-Meldung in einen lesbaren Satz samt Vorschlag.

Eine typische Meldung liest sich so: avc: denied { read } for pid=1234 comm=„httpd“ name=„index.html“ scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0. Übersetzt heißt das: Der Webserver (httpd_t) wollte eine Datei lesen, die als Benutzerdatei gekennzeichnet ist (user_home_t). Das ist genau der Fall, der auftritt, wenn Webinhalte aus einem Heimatverzeichnis kopiert statt am Zielort erzeugt wurden.

03

Kontexte richtig setzen

Der häufigste Fall überhaupt: Daten liegen an einem Ort, für den die Standardregeln nichts vorsehen, oder sie wurden verschoben statt kopiert.

Dauerhaft korrigieren
# Regel für den Pfad hinterlegen (dauerhaft!)
sudo semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"

# Vorhandene Dateien entsprechend kennzeichnen
sudo restorecon -Rv /web

# Kontrolle
ls -Zd /web
sudo semanage fcontext -l | grep '/web'

chcon ändert den Kontext ebenfalls, aber nur bis zum nächsten restorecon oder Relabel. Für dauerhafte Änderungen ist semanage fcontext plus restorecon der richtige Weg.

Ports und Booleans
# Dienst soll auf einem anderen Port lauschen
# -a legt neu an, -m aendert eine bestehende Zuordnung.
# 8080 gehoert bereits http_cache_port_t, dort braucht es -m:
sudo semanage port -a -t http_port_t -p tcp 8088
sudo semanage port -l | grep http_port

# Vorgefertigte Schalter für häufige Anforderungen
sudo getsebool -a | grep httpd | head -20
sudo setsebool -P httpd_can_network_connect on

Das -P ist entscheidend, sonst gilt der Schalter nur bis zum Neustart. Booleans lösen sehr viele Fälle, für die sonst eine eigene Regel nötig wäre: Prüfe immer zuerst, ob es einen passenden gibt. Achtung bei bereits belegten Ports: semanage port -a bricht dann mit Port tcp/8080 already defined ab, zum Umtypisieren ist -m noetig.

04

Wenn wirklich eine eigene Regel nötig ist

Selten, aber es kommt vor: eine Anwendung tut etwas, das kein Standardtyp abdeckt. Dann erzeugst du ein eigenes Modul, statt den Schutz für das ganze System zu lockern.

Modul aus den Verweigerungen bauen
# 1. Anwendung im permissive-Modus laufen lassen, damit alle nötigen
#    Zugriffe protokolliert werden, statt beim ersten abzubrechen
sudo semanage permissive -a httpd_t

# 2. Anwendung vollständig durchtesten (alle Funktionen!)

# 3. Regel aus den gesammelten Meldungen erzeugen
sudo ausearch -m avc -c httpd --raw | audit2allow -M meinehttpd

# 4. ERST LESEN, dann laden
cat meinehttpd.te
sudo semodule -i meinehttpd.pp

# 5. Ausnahme wieder zurücknehmen
sudo semanage permissive -d httpd_t

Schritt 4 ist keine Formalität. audit2allow erzeugt Regeln für alles, was protokolliert wurde, auch für Zugriffe, die ein Angriffsversuch waren. Ungeprüft übernommen reißt du damit genau die Lücke auf, die SELinux geschlossen hatte.

Gut zu wissen

Häufige Fragen zu SELinux-Grundlagen

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Sollte man SELinux deaktivieren, wenn ein Dienst nicht läuft?
Nein, das entfernt eine Schutzschicht, die den Schaden eines kompromittierten Dienstes begrenzt, und ist auf Systemen mit Grundschutz- oder Compliance-Anforderungen kaum vertretbar. Sinnvoller ist es, den Modus temporär mit setenforce 0 auf permissive zu setzen, die entstehenden Denials zu sammeln und daraus die passenden Kontexte, Booleans oder Portregeln abzuleiten.
Was ist der Unterschied zwischen permissive und enforcing?
Im Enforcing-Modus blockiert der Kernel Zugriffe, die die Policy nicht erlaubt, und protokolliert sie. Im Permissive-Modus wird derselbe Zugriff nur protokolliert, aber durchgelassen, was den Modus zur Fehlersuche brauchbar macht. Permissive ist ein Diagnosewerkzeug für eine begrenzte Zeit, kein Dauerzustand, und es unterscheidet sich klar von disabled, bei dem gar keine Labels mehr gepflegt werden.
Wann brauche ich restorecon und wann chcon?
restorecon setzt Labels auf das zurück, was die Policy und die fcontext-Regeln vorsehen, und ist deshalb der richtige Befehl nach einem semanage fcontext oder nach dem Verschieben von Dateien mit mv. chcon ändert ein Label direkt und wird beim nächsten relabel überschrieben, taugt also zum schnellen Test einer Vermutung, nicht für eine dauerhafte Konfiguration.
Ist audit2allow eine gute Lösung für SELinux-Fehler?
audit2allow ist nützlich, um aus Denials einen Regelentwurf zu erzeugen, liefert aber oft breitere Rechte als nötig und verdeckt die eigentliche Ursache, wenn das Problem nur ein falsches Label war. Gute Praxis ist es, zuerst Kontext, Boolean und Portregel zu prüfen und ein Modul erst zu bauen, wenn der Anwendungsfall tatsächlich nicht von der Standard-Policy abgedeckt ist.
Was ist der Unterschied zwischen SELinux und AppArmor?
Beide sind Mandatory-Access-Control-Systeme über das LSM-Interface des Kernels, arbeiten aber unterschiedlich. SELinux labelt Prozesse und Objekte und entscheidet anhand von Typen, was ein feingranulares und systemweites Modell ergibt, das dafür mehr Einarbeitung verlangt. AppArmor arbeitet pfadbasiert mit Profilen pro Programm und ist schneller zu lesen, aber weniger tiefgreifend. Auf RHEL und seinen Derivaten ist SELinux gesetzt, auf SUSE und Ubuntu ist AppArmor die Voreinstellung.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

SELinux im eigenen Tempo aufbauen

Wir bilden SELinux in drei aufeinander aufbauenden Trainings ab. SEL1 vermittelt Grundlagen und Administration, also Kontexte, Modi und die tägliche Fehlersuche. SEL2 geht in Konfiguration und Management mit Booleans, semanage und Policy-Verwaltung im Bestand. SEL3 behandelt die Entwicklung eigener Policy-Module. Alle Kurse gibt es als Präsenztraining und Live-Online, auf Wunsch auch als Inhouse-Termin mit deinen eigenen Systemen. Wenn du nicht sicher bist, welche Stufe passt, sprich uns an, wir schauen uns deine Ausgangslage gemeinsam an.