# SELinux Troubleshooting: Denials analysieren und beheben

TL;DR / Management Summary Wenn etwas unter RHEL/Rocky nicht funktioniert, obwohl die Rechte stimmen, ist fast immer SELinux der Grund. Ein Senior Admin “rät” nicht, was das Problem ist – er liest die AVC (Access Vector Cache) Meldungen im Audit-Log. Mit Werkzeugen wie sealert, audit2why und audit2allow lassen sich Blockaden in Sekunden identifizieren und bei Bedarf durch eigene Policy-Module sauber beheben, ohne SELinux global zu deaktivieren.

# 1. Einführung & Architektur

Woher kommen die ‘Access Denied’ Meldungen?

Jeder Zugriff, den SELinux verweigert, wird vom Kernel an den Audit-Dämon (auditd) gemeldet. Diese Meldungen heißen AVC Denials.

graph TD
    A[Kernel: SELinux Deny] --> B[auditd Daemon]
    B --> C[/var/log/audit/audit.log]
    D[Admin] -->|Query| E[ausearch / aureport]
    D -->|Analyze| F[sealert / audit2why]
    D -->|Create Module| G[audit2allow]
    G -->|Load| H[Kernel Policy]

# 2. Denials finden

Die Nadel im Heuhaufen.

# Im Audit-Log suchen

# Suche nach allen AVC Meldungen des heutigen Tages
sudo ausearch -m AVC -ts today

# via Journalctl (Bequemer)

journalctl -xe | grep -i selinux

# 3. Analyse-Tools

Verstehen, warum blockiert wurde.

# audit2why

Übersetzt die kryptische Audit-Meldung in menschliche Sprache und schlägt oft Booleans vor.

sudo ausearch -m AVC -ts recent | audit2why

# sealert (Teil von setroubleshoot-server)

Gibt detaillierte Berichte mit Lösungsvorschlägen aus.

sudo sealert -a /var/log/audit/audit.log

# 4. Eigene Policy-Module erstellen mit audit2allow

Die letzte Instanz.

Wenn kein Label und kein Boolean hilft (z.B. bei einer sehr speziellen Eigenentwicklung), bauen wir ein eigenes Modul.

# Schritt 1: Denial provozieren

Stellen Sie sicher, dass SELinux auf Permissive steht, damit die Applikation durchläuft und alle benötigten Zugriffe geloggt werden.

sudo setenforce 0
# Applikation nutzen / Fehler provozieren

# Schritt 2: Modul generieren

sudo ausearch -m AVC -ts recent | audit2allow -M my_custom_app

Dies erstellt zwei Dateien: my_custom_app.te (Type Enforcement Source) und my_custom_app.pp (Kompiliertes Paket).

# Schritt 3: Modul laden

sudo semodule -i my_custom_app.pp
sudo setenforce 1

# 5. Troubleshooting & “War Stories”

Praxisfallen.

# Story 1: “Der Dontaudit-Fluch”

Symptom: Eine Applikation funktioniert nicht (Permission Denied), aber es tauchen absolut keine AVC-Meldungen im Audit-Log auf. Ursache: Die Policy enthält dontaudit Regeln für bekannte, harmlose Verstöße, um das Log nicht zu fluten. Manchmal ist Ihr Fehler dort “mitgefangen”. Lösung: Deaktivieren Sie die Unterdrückung temporär:

sudo semodule -DB
# Fehler provozieren, analysieren, danach wieder einschalten:
sudo semodule -B

# Story 2: “Das generische Modul”

Symptom: Ein Admin nutzt audit2allow ohne Filterung und erlaubt versehentlich zu viel. Ursache: audit2allow nimmt alle Denials im Log. Wenn gleichzeitig ein anderer Dienst (z.B. ein bösartiges Skript) blockiert wurde, wird dessen Zugriff auch erlaubt! Lösung: Filtern Sie die Suche immer mit einem Tag (-k) oder dem Programmnamen (-comm).

# 6. Fazit & Empfehlung

• Labels First: Prüfen Sie immer erst restorecon, bevor Sie Module bauen.
• Booleans Second: Prüfen Sie getsebool, ob es eine eingebaute Lösung gibt.
• Module Last: Eigene Module sind schwerer zu warten und sollten der letzte Ausweg sein.
• Auditd: Stellen Sie sicher, dass auditd immer läuft. Ohne Logs sind Sie blind.

# Anhang: Cheatsheet