SELinux verweigert einem Dienst den Zugriff (AVC denial)? Statt dauerhaft setenforce 0 lieber das Audit-Log lesen und Kontext oder Boolean korrigieren.
Aufwand:
ca. 20 Min.
Voraussetzung:
Terminal, sudo-Rechte
Das Symptom
Der Dienst ist installiert, die Konfiguration stimmt, die Dateirechte sehen
korrekt aus – und trotzdem verweigert das Programm den Start oder den Zugriff auf
eine Datei mit einem beharrlichen Permission denied. Im Log des Systems
taucht dazu eine kryptische Zeile mit avc: denied auf. Kein Tippfehler, kein
falsches Passwort: SELinux hat entschieden, dass hier etwas nicht sein darf.
Die „Layer 8“-Wahrheit
SELinux blockiert nichts aus Boshaftigkeit – es setzt eine Regel durch, die
besagt, dass genau dieser Prozess auf genau dieses Objekt nicht zugreifen soll.
Der Reflex, das Problem mit setenforce 0 verschwinden zu lassen, behebt nicht
den Fehler, sondern entlässt den Wächter, der ihn meldet. Danach läuft der Dienst,
weil überhaupt nichts mehr geprüft wird – ein Sicherheitsmodell wird für einen
Dateizugriff geopfert. Die eigentliche Information steckt im Audit-Log: Jede
Verweigerung wird als AVC-Eintrag protokolliert und sagt genau, wer worauf nicht
durfte. Aus dieser Meldung ergibt sich fast immer die richtige, chirurgische
Lösung – ein Boolean umlegen, den Dateikontext korrigieren oder eine eng
begrenzte Regel erzeugen. setenforce 0 ist ein Diagnosewerkzeug für zwei
Minuten, kein Dauerzustand. Wer es dauerhaft nutzt, hat den Fehler nicht gelöst,
sondern nur das Warnschild abgeschraubt.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Prüfen, ob SELinux wirklich die Ursache ist
Zuerst feststellen, in welchem Modus SELinux läuft. Steht es auf 'Enforcing', werden Regeln durchgesetzt und ein Verstoß führt zur Blockade – der wahrscheinliche Verdächtige, wenn ein Dienst grundlos scheitert:
getenforce
2.
Das Audit-Log nach der Verweigerung durchsuchen
Statt zu raten, die Quelle lesen. Jede Blockade schreibt SELinux als AVC-Meldung ins Audit-Log. Diese Suche zeigt die jüngsten Verweigerungen mit Prozess, Zielobjekt und der Aktion, die untersagt wurde:
sudo ausearch -m avc -ts recent
3.
Kurz gegentesten – aber nur zum Diagnostizieren
Um sicher zu sein, dass wirklich SELinux und nicht etwa ein Dateirechte-Problem im Weg steht, lässt sich der Enforcing-Modus vorübergehend abschalten. Funktioniert der Dienst danach, ist SELinux bestätigt. Wichtig: Das ist kein Zielzustand, sondern nur ein Test – direkt danach wieder einschalten.
Die passende Lösung wählen: Boolean statt Holzhammer
Viele legitime Zugriffe sind in der Policy bereits vorgesehen und lassen sich per Boolean freischalten – etwa der Netzzugriff eines Webservers. Das -P schreibt die Änderung dauerhaft, ohne SELinux insgesamt zu schwächen. Welcher Boolean gebraucht wird, verrät oft schon die AVC-Meldung:
sudo setsebool -P <boolean_name> on
5.
Für Sonderfälle: eine gezielte Regel aus dem Log erzeugen
Deckt kein Boolean den Fall ab, lässt sich aus den protokollierten Verweigerungen eine eng zugeschnittene Erlaubnis-Regel ableiten. audit2allow zeigt, was genau erlaubt werden müsste. Die vorgeschlagene Regel vor dem Übernehmen lesen und verstehen – blind alles zu erlauben wäre nur setenforce 0 in langsam:
sudo ausearch -m avc -ts recent | audit2allow -w
Häufige Fragen (FAQ)
?Ist setenforce 0 nicht die einfachste Lösung?
Es ist die einfachste – und die schlechteste. setenforce 0 schaltet SELinux systemweit in den Permissive-Modus und beseitigt damit nicht das Problem, sondern nur den Wächter, der es meldet. Der Zugriff klappt dann, weil gar nichts mehr geprüft wird – auch bei allen anderen Diensten nicht. Als Diagnose-Schritt für ein paar Minuten ist das legitim: Läuft es im Permissive-Modus, liegt es wirklich an SELinux. Als Dauerzustand gibt man den Schutz auf, für den man das System eigentlich betreibt.
?Woher weiß ich, was SELinux überhaupt blockiert hat?
Aus dem Audit-Log. Jede Verweigerung landet dort als AVC-Eintrag (Access Vector Cache) mit Prozess, Zieldatei und der verweigerten Aktion. 'ausearch -m avc -ts recent' filtert die letzten dieser Meldungen heraus. Das ist der Unterschied zwischen Raten und Wissen: Der Eintrag sagt exakt, welcher Kontext oder welcher Boolean fehlt – und damit auch, wie die richtige Lösung aussieht.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Nach dem Verschieben von Dateien meldet ein Dienst 'Permission denied', obwohl die Rechte stimmen? Der SELinux-Kontext fehlt, restorecon repariert ihn.
OSLästigFailed to download metadata for repository
npm warnt nach der Installation vor Sicherheitslücken? Nicht jede ist gefährlich — und ein blindes npm audit fix kann mehr kaputt machen, als es behebt.
Nach der Installation von akmod-nvidia startet Fedora ohne Nvidia-Treiber? Oft ist das Kernelmodul beim Neustart noch nicht fertig gebaut. akmods baut es.
nginx liefert 502 Bad Gateway? Der Upstream antwortet nicht wie erwartet. So findest du Dienst-, Timeout- und Berechtigungsursachen und reparierst sie.