SELinux-Fehler diagnostizieren und gezielt erlauben: von permissive bis Policy-Module

Wenn ein Dienst „Permission denied“ meldet, ist SELinux-Fehlerdiagnose ein zentraler Schritt: Das System setzt Mandatory Access Control (MAC) durch, die über klassische Unix-Rechte hinaus entscheidet. In dieser Anleitung erfahren Sie praxisnah, wie Sie SELinux-Fehler diagnostizieren, AVC‑Denials bewerten, permissive kontrolliert einsetzen, Labels, Ports und Booleans korrigieren und – nur wenn nötig – kleine Policy‑Module erstellen. Zielgruppe: Administratoren, System Engineers, Operatoren und technische Dienstleister. Schwerpunkt: sichere Betriebsabläufe, Docker/Podman-Fallstricke, Prüfsequenzen und Rückfallstrategien.

Kurz: Was SELinux macht und wie Denials erscheinen

SELinux ist eine Mandatory Access Control (MAC). Im Unterschied zur gewöhnlichen Dateirechteverwaltung (Discretionary Access Control, DAC) entscheidet SELinux anhand von Sicherheitskontexten (z. B. user:role:type:level), welche Domain (ein Prozesskontext, z. B. httpd_t oder container_t) welche Aktionen auf ein Objekt (Datei, Socket, port) ausführen darf. Ein verweigerter Zugriff wird als AVC Denial (Access Vector Cache) protokolliert und ist die primäre Diagnosequelle.

Systematische Prüfsequenz: so arbeiten Sie zielgerichtet

Arbeiten Sie nach einer festen Abfolge, um unnötige Änderungen zu vermeiden und die Blast Radius zu reduzieren. Reihenfolge: Status → Reproduzieren → Log sammeln → Kontextanalyse → Behebungsstrategie (Label/Port/Boolean → permissive für Sammlung → Policy‑Modul) → Test → Rückrollen.

Status prüfen und Logs sichern

# Modus und Policy
sestatus
getenforce

# Audit-Log (RHEL/Fedora) ansehen
sudo tail -n 200 /var/log/audit/audit.log

# Kurz-Report über AVCs
sudo aureport --avc --summary

Bevor Sie Änderungen vornehmen: Kopieren Sie relevante Logabschnitte in Ihr Incident-Ticket. Das erleichtert Review, Test und Rollback.

Denial reproduzieren und zeitlich eingrenzen

# AVC-Einträge seit Reproduktionszeitpunkt
sudo ausearch -m AVC,USER_AVC -ts recent

# AVC-Einträge in Datei schreiben
sudo ausearch -m AVC -ts 2026-07-27 10:00:00 > /tmp/avc.log

Wichtig: Führen Sie den fehlerhaften Ablauf im möglichst isolierten Testfenster aus, damit die gesammelten AVCs verständlich bleiben.

AVC-Log: Beispiel und Feldauslegung

# Beispiel eines AVC-Eintrags (gekürzt)
type=AVC msg=audit(1627392000.123:456): avc:  denied  { write } for  pid=2345 comm="httpd" name="uploads" dev="sda1" ino=12345 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file

Wichtigste Felder: scontext (Quellkontext = Prozessdomäne), tcontext (Zielkontext = Dateityp), tclass (Objektklasse, z. B. file, tcp_socket) und die Aktion (z. B. write). Wenn tcontext nicht dem erwartetem Typ entspricht (z. B. usr_t statt httpd_sys_rw_content_t), dann schlägt SELinux Alarm — selbst wenn Unix-Rechte korrekt sind.

audit2why als erste Interpretation

# Erklärung der Gründe
sudo ausearch -m AVC -ts recent | sudo audit2why

audit2why ordnet Denials zu Policy-Regeln und gibt Hinweise (z. B. welcher Boolean helfen könnte). Nutzen Sie die Ausgabe als Hinweisgeber, nicht als automatischen Fix-Plan.

Labels korrigieren: chcon vs. semanage fcontext & restorecon

chcon ändert den Kontext eines Objekts sofort, ist aber nicht persistent: Ein relabel (bei Restore oder systemweiter Relabel) überschreibt es. semanage fcontext hinterlegt eine dauerhafte Regel in der SELinux-Konfigurationsdatenbank; restorecon wendet diese Regel auf Dateien an.

# Schnell: prüfen
ls -lZ /var/www/html/uploads

# Persistente Zuordnung erstellen
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"
sudo restorecon -Rv /var/www/html/uploads

# Nur simuliert anzeigen, was verändert würde
sudo restorecon -Rvn /var/www/html/uploads

Relabel bei Systemmigration oder Restore

Nach einem Restore von Backups oder einer Migration müssen SELinux-Kontexte oft neu gesetzt werden. Für eine komplette, geplante Relabel-Aktion verwenden Sie:

# Vollständiges Relabel beim nächsten Boot (vorsichtig einsetzen)
sudo touch /.autorelabel
sudo reboot

Alternativ: gezielte restorecon-Aufrufe auf betroffenen Pfaden. Bei großen Dateibeständen planen Sie Zeitfenster und prüfen I/O‑Last.

Ports, Booleans und Netzwerkzugriffe

SELinux regelt auch Portzuordnungen und vordefinierte Verhaltensoptionen (Booleans). Wenn ein Dienst an einem Nicht‑Standardport läuft oder Netzwerkzugriffe benötigt, prüfen Sie Ports und Booleans vor einem Policy‑Modul.

# Port-Typen listen und Port hinzufuegen
sudo semanage port -l | grep http_port_t || true
sudo semanage port -a -t http_port_t -p tcp 8081

# Boolean anzeigen und permanent setzen
getsebool -a | grep '^httpd_'
sudo setsebool -P httpd_can_network_connect on

Booleans sind policy‑definierte Schalter. Verwenden Sie -P, um die Einstellung persistent zu machen (über Reboots hinweg).

Docker & Podman: Volumes, :Z/:z und typische Betriebsfallen

Container-Prozesse laufen in speziellen SELinux-Domains (z. B. container_t). Bei gemounteten Host-Volumes muss der Hostpfad passend gelabelt werden, sonst bleiben Zugriffe geblockt, obwohl Unix-Rechte korrekt sind. Engines bieten praktische Relabel-Marken.

:Z vs :z — praktische Bedeutung

• :Z erstellt ein privates Label für diesen Container (sicherer für einzelne Container).
• :z erlaubt ein geteiltes Label für mehrere Container (geeignet für Shared-Data, aber weniger restriktiv).

# Docker: Hostpfad für Container relabeln
docker run --rm -v /srv/appdata:/var/lib/app:Z myimage

# Podman hat analoges Verhalten
podman run --rm -v /srv/appdata:/var/lib/app:Z myimage

Wichtig: Relabels verändern Host-Label. Informieren Sie Backup-Jobs, Monitoring-Agents und Hostprozesse, da diese gegebenenfalls andere Erwartungen an SELinux-Kontexte haben.

Container und NFS

Bei NFS ist SELinux besonders sensibel: NFS-Server übergeben nicht immer SELinux-Kontexte. In solchen Fällen sind spezielle Booleans, NFS-Server-Einstellungen oder alternative Storage-Strategien zu prüfen. Planen Sie Container‑Workloads mit NFS‑Zugriff frühzeitig, sonst entstehen langfristige Policy‑Ausnahmen.

Policy‑Module: kontrolliert erstellen, reviewen und deployen

Erstellen Sie Module nur, wenn Labels, Ports und Booleans das Problem nicht lösen. Module sind nachhaltig und sollten wie jede Konfigurationsänderung versioniert, reviewed und getestet werden.

Empfohlener Ablauf für Module

1. Domain temporär permissive schalten (nur für Sammlung).
2. Relevanten Workflow durchführen und AVCs sammeln.
3. audit2allow verwenden, .te prüfen und manuell einschränken.
4. Modul testen in Staging, semodule -i in produktiver Rollout-Phase mit Change-Window.
5. Rollback testen (semodule -r) und Dokumentation anlegen.

# Beispiel: Modul erzeugen und installieren
sudo semanage permissive -a httpd_t
# Tests durchführen und AVCs sammeln
sudo ausearch -m AVC -ts recent > /tmp/avc.log
sudo semanage permissive -d httpd_t
sudo audit2allow -M local_app_fix -i /tmp/avc.log
# .te prüfen, dann installieren
cat local_app_fix.te
sudo semodule -i local_app_fix.pp

# Modul entfernen (Rollback)
sudo semodule -r local_app_fix

Prüfen Sie .te sorgfältig: audit2allow generiert Regeln auf Basis beobachteter Aktivitäten; diese Regeln können zu breit sein und sollten manuell eingeschränkt werden, z. B. nach Operation (write vs append) oder Zielobjekten.

Praxisbeispiel: Webserver kann nicht in Upload-Verzeichnis schreiben

1. Fehlermeldung prüfen und Zeitpunkt notieren.
2. AVCs sammeln: ausearch/Audit-Log.
3. Kontexte prüfen: ls -lZ, ps -eZ.
4. Erst restorecon versuchen; falls nötig semanage fcontext setzen.
5. Wenn Netzwerkzugriff nötig: Booleans/Ports prüfen.
6. Wenn nichts passt: permissive kurz setzen, sammeln, Modul bauen und testen.

# Diagnose-Schritte
ls -lZ /var/www/html/uploads
sudo ausearch -m AVC -ts recent | sudo audit2why
sudo restorecon -Rv /var/www/html/uploads
# Falls persistent benoetigt
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"
sudo restorecon -Rv /var/www/html/uploads

Backup, Restore und Migration: SELinux-Kontexte erhalten

Beim Kopieren oder Migrieren von Daten sind SELinux-Kontexte Extended Attributes (xattrs). Verwenden Sie Tools, die xattrs erhalten, sonst sind nach dem Restore Denials wahrscheinlich.

# Rsync inkl. xattrs, ACLs und besonderen Flags
rsync -aHAX --numeric-ids --delete /srv/source/ /srv/dest/

# Nach Restore gezielt relabeln
sudo restorecon -Rv /srv/dest

Planen Sie Migrationen mit einem Testlauf und Relabel-Checks; für große Datenbestände kann ein schrittweises Vorgehen mit Stichproben sinnvoll sein.

Monitoring, Alerting und Automatisierung

Regelmäßige AVC-Analyse hilft, Regressionen zu erkennen. Tools wie auditd/aureport, setroubleshoot (sealert) oder zentrale Log-Pipelines (ELK, Splunk) sind sinnvoll. Legen Sie in Ihrem Monitoring Schwellen für AVC‑Raten fest und erzeugen Sie Tickets bei plötzlichen Peaks.

# Schnelle Übersicht
sudo aureport --avc --summary

# sealert für verständliche Hinweise
sudo sealert -a /var/log/audit/audit.log | head -n 200

Dokumentieren Sie jede Änderung (semanage, setsebool, semodule) in Ihrem CMDB/Change‑Ticket inklusive Gründe, Test-VM und Rollback-Plan.

Konfigurationsmanagement: Beispiel-Ansible-Task

- name: Persistente SELinux-Fcontext für Uploads setzen
  become: true
  command: >
    semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"
  changed_when: false

- name: restorecon auf Uploads anwenden
  become: true
  command: restorecon -Rv /var/www/html/uploads

In Automatisierungs-Playbooks sollten Sie Idempotenz testen und Änderungen durch Dry‑Runs (restorecon -vn) prüfen, bevor Sie produktiv ausrollen.

Abschluss-Checkliste vor Produktivänderung

• AVC-Log-Backup in Ticket anhängen.
• Fix-Priorität prüfen: Label → Port → Boolean → Modul.
• Permissive nur kurz und dokumentiert einsetzen.
• Modul-Dateien (.te/.pp) ins Git, Review und Test-VMs nutzen.
• Rollback geprüft und im Ticket vermerkt.

Fazit

SELinux bietet starke zusätzliche Sicherheit, erfordert aber systematisches Arbeiten: Log-basierte Diagnose, bevorzugte Korrektur via Label/Port/Boolean, gezieltes Sammeln in permissive-Modus und nur danach schlanke Policy‑Module. Insbesondere bei Container-Workloads planen Sie SELinux-Konformität bereits in der Architekturphase. Versionieren, testen und dokumentieren Sie jede Policy-Änderung, damit Betrieb, Backup/Restore und Audits zuverlässig bleiben.

FAQ

Siehe das FAQ am Ende des Beitrags für schnelle Antworten auf häufige Fragen.

SELinux-Fehler diagnostizieren: CI/CD, Rollout und Governance

Über reine Einzelfixes hinaus lohnt es sich, SELinux-Artefakte in Ihre Betriebs- und Deployment-Prozesse zu integrieren. Das reduziert langfristig Risiko, sorgt für Reproduzierbarkeit und verhindert, dass im Betrieb breitflächige, unsaubere Policy-Änderungen entstehen.

Policy-Module in CI: Sammlung, Review, Build

Automatisieren Sie die Erzeugung und Prüfung von Policy-Vorschlägen. Aufbau: Tests in einer isolierten Staging-Umgebung (möglichst identisch zur Produktion) kurzzeitig permissive Domains erlauben, AVCs sammeln, audit2allow als Ausgangspunkt nutzen, die .te-Datei ins Repository prüfen und erst nach manueller Einschränkung bauen.

# CI-Schritte: Beispiel (vereinfachte Darstellung)
# 1) permissive für Domain setzen (nur Stage)
sudo semanage permissive -a myapp_t
# 2) Integrationstests laufen lassen, AVCs sammeln
sudo ausearch -m AVC -ts recent > avc-stage.log
# 3) audit2allow ausführen und .te erzeugen
sudo audit2allow -M myapp_fix -i avc-stage.log
# 4) statische Prüfung (Developer/Reviewer prüft myapp_fix.te)
# 5) Build & Paket
checkmodule -M -m -o myapp_fix.mod myapp_fix.te
semodule_package -o myapp_fix.pp -m myapp_fix.mod

Das erzeugte .te-File gehört ins Git, inklusive Review-Comments und Tests, bevor das .pp in Staging installiert wird.

Sicherer Rollout: Canary, Monitoring, Revert

• Führen Sie ein Canary-Deployment durch: Installieren Sie das Modul zuerst auf einer kleinen Hostgruppe.
• Verfolgen Sie AVC-Raten und Geschäftsmetriken parallel; legen Sie Alarme auf plötzliche Zuwächse an.
• Testen Sie den Revert-Pfad: semodule -r modulname muss ohne Nebenwirkungen sauber entfernen und Funktionalität wiederherstellen.

Versions- und Namenskonvention

Benennen Sie Module mit Service-, Ticket-Nummer und Version (z. B. myapp_fix-T1234-v1). Bewahren Sie .te/.pp und audit-Logs im Change-Ticket/Repo auf, damit Audit und Postmortem nachvollziehbar sind.

Diversität prüfen: Distributionen, Kernel, Container-Engines

SELinux-Policy-Feinheiten können zwischen RHEL/CentOS, Fedora und Debian/Ubuntu variieren (unterschiedliche Policy-Pakete und Booleans). Testen Sie Module auf der Matrix, die Ihre Landschaft abbildet: distro-Version × Kernel-Version × Container-Engine (Docker/Podman) × Storage-Typ (lokal/NFS).

Betriebsrisiken und harte Grenzen

Achten Sie auf Privilege-Erosion: Breite Allow-Regeln (z. B. allow container_t self:process) öffnen Angriffsflächen. Begrenzen Sie Regeln auf konkrete Objektklassen, Operationen und Pfad‑Patterns. Dokumentieren Sie Ausnahmeregeln mit Risikoabwägung, Zeitfenstern und Ownership für spätere Reviews.

Automatisierte Preflight-Checks

Vor Produktivinstallationen empfehlen sich automatisierte Preflight-Checks: semodule -l (vorher/nacher), test-Execs der kritischen Use-Cases, sowie automatische Diff-Analyse der erzeugten .te auf erlaubte Muster. Diese Checks lassen sich leicht in CI-Pipelines einbauen und verhindern unabsichtliche Policy-Inflation.

Solche Governance-Maßnahmen machen SELinux-Änderungen transparent, reproduzierbar und sicherer für Betrieb und Compliance — ein klarer Vorteil für Betreiber individueller Unternehmenssoftware und prozessnahe Softwarelösungen.

Für dieses Thema sind auch Selinux Denial und Audit.log Auswerten wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.