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.
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.
Vom AVC-Denial zur richtigen Maßnahme
- 01 Denial mit ausearch finden
- 02 Kontext von Prozess und Objekt prüfen
- 03 Falsches Label? semanage fcontext und restorecon
- 04 Vorgesehener Anwendungsfall? Boolean setzen
- 05 Abweichender Port? semanage port ergänzen
- 06 Erst dann eigenes Policy-Modul bauen
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.
Kurse zu SELinux-Grundlagen bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Häufige Fragen zu SELinux-Grundlagen
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktSollte man SELinux deaktivieren, wenn ein Dienst nicht läuft?
Was ist der Unterschied zwischen permissive und enforcing?
Wann brauche ich restorecon und wann chcon?
Ist audit2allow eine gute Lösung für SELinux-Fehler?
Was ist der Unterschied zwischen SELinux und AppArmor?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
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.