SELinux verweigert einen Dienstvorgang · Linux Fix Lab

Symptome und Geltungsbereich

Ein eingeschränkter Dienst scheitert trotz passender normaler Dateirechte.
Audit-Protokolle zeigen abgelehnte Vorgänge mit Quell- und Zielkontext.

Betroffene Umgebung

Linux mit SELinux und Audit-Werkzeugen; Audit-Protokolle brauchen meist Root-Leserechte. Paketnamen unterscheiden sich.

Erkennbare Meldungen (synthetische Beispiele)

audit: type=1400 avc: denied { read } for pid=410 comm="example" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file permissive=0

Kontexte und Objektklasse führen die Diagnose; der Eintrag allein rechtfertigt keine Freigabe des Vorgangs.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Datei- oder Portlabel oder ein dokumentierter Boolean passt möglicherweise nicht zur Dienstkonfiguration.
Anwendung oder Regelpaket kann einen Fehler enthalten, der eine unterstützte Aktualisierung benötigt.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Schreibgeschützte Audit-Suche; mit den nötigen Protokoll-Leserechten ausführen. recent wählt ein kurzes Zeitfenster; bei älterem Fehler einen passenden Zeitraum nutzen.

ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent -i

Ergebnis einordnen: Abgelehntes Recht, comm, scontext, tcontext und tclass vergleichen. permissive=1 protokolliert eine mögliche, nicht erzwungene Ablehnung.

Prüfschritt 2

Liest den aktuellen SELinux-Modus, ohne ihn zu ändern.

getenforce

Ergebnis einordnen: Enforcing stützt eine aktive Regelbeschränkung; Permissive protokolliert ohne Erzwingen, bei Disabled ist eine andere Erklärung für die unmittelbare Sperre nötig.

Nächste Schritte nach Befund

Dienstpfade, Ports oder Booleans an dokumentierte Regeln anpassen

Wenn die Ablehnung eine gewollte abweichende Dienstkonfiguration betrifft, deren dokumentierte SELinux-Labels und Booleans prüfen. Zuerst falsche Labels korrigieren; sonst nur die passende Portzuordnung oder einen engen Boolean nach Notieren seines bisherigen Werts ändern.

Vorsicht: SELinux nicht global permissiv setzen oder als erste Reaktion ein audit2allow-Modul erzeugen. Die Ablehnung kann gewollter Schutz sein.

Wiederherstellung / Rücknahme: Boolean oder Portzuordnung und Diensteinstellung anhand der gesicherten Werte wiederherstellen; den weiter aktiven erzwingenden Modus prüfen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Unterstützte Regel- oder Anwendungskorrektur verwenden

Wenn Labels und dokumentierte Einstellungen stimmen, Distributionsaktualisierungen von Regel und Anwendung auf denselben abgelehnten Vorgang prüfen. Eine passende unterstützte Korrektur mit Paket-/Konfigurationssicherung einsetzen oder den minimal reproduzierbaren Eintrag mit bereinigten vertraulichen Pfaden melden.

Vorsicht: Ein weites lokales Freigabemodul kann einen kompromittierten oder falsch konfigurierten Dienst verdecken. Den ursprünglichen AVC-Beleg erhalten.

Wiederherstellung / Rücknahme: Den funktionierenden Snapshot oder unterstützte zusammenpassende Paketstände und die gesicherte Konfiguration wiederherstellen; einzelne Regeldowngrades benötigen Distributionshinweise.