Kurz & knapp: Die wichtigsten Fakten
- SELinux-Protokolle finden Sie in /var/log/audit/audit.log – dort stehen alle verweigerten Zugriffe.
- Im Permissive-Modus protokolliert SELinux, ohne zu blockieren – ideal zur Fehlersuche.
- Mit `ausearch` und `audit2allow` analysieren Sie Verweigerungen und erstellen eigene Richtlinienmodule.
- Booleans und Dateikontexte (Labels) sind die häufigsten Stellschrauben für die Konfiguration.
1. Grundlagen: Was sind SELinux-Richtlinien und wo liegen die Logs?
Was ist SELinux und warum ist es wichtig?
Bevor wir uns in die Tiefe der Log-Analyse stürzen, müssen wir die Basis verstehen. SELinux (Security-Enhanced Linux) implementiert eine Mandatory Access Control (MAC) – im Gegensatz zur herkömmlichen Discretionary Access Control (DAC). Während bei DAC der Benutzer über Zugriffsrechte entscheidet, setzt SELinux eine zentrale Richtlinie durch, die selbst Root-Prozesse einschränkt.
Kurz gesagt :
- SELinux-Protokolle liegen in `/var/log/audit/audit.log`; dort werden alle verweigerten Zugriffe (AVC-Denials) erfasst.
- Der Permissive-Modus protokolliert Ablehnungen, ohne zu blockieren – ideal zur Fehlersuche, aber SELinux nicht komplett deaktivieren.
- Mit `ausearch` und `audit2allow` analysieren Sie Denials und erstellen eigene Richtlinienmodule.
- Booleans und Dateikontexte (Labels) sind die zentralen Konfigurationspunkte; falsche Labels wie `user_home_t` bei `httpd_t` verursachen typische Fehler.
Für Server in französischen Rechenzentren wie OVH oder Scaleway ist das kein Luxus, sondern eine Notwendigkeit. Auch die ANSSI empfiehlt SELinux für gehärtete Systeme. Es ist quasi ein Sicherheitsnetz, das Angriffe abfängt, bevor sie Schaden anrichten.
Die zentralen Log-Dateien im Überblick
Die wichtigste Datei für SELinux-Ereignisse ist `/var/log/audit/audit.log`. Hier landen alle Access Vector Cache (AVC) Meldungen. Zusätzlich finden Sie allgemeine Systemmeldungen in `/var/log/messages` oder `/var/log/syslog` – je nach Distribution. Für die gezielte Analyse nutzen Sie Werkzeuge wie `ausearch` und `aureport`.
Die wichtigsten Befehle für den Einstieg
- `getenforce` – zeigt den aktuellen Status (Enforcing, Permissive oder Disabled)
- `sestatus` – liefert detaillierte Informationen zur SELinux-Konfiguration
- `ausearch -m avc -ts recent` – listet die letzten Ablehnungen auf
Mit diesen drei Befehlen haben Sie schon die halbe Miete. Sie sehen sofort, ob SELinux aktiv ist und was es blockiert.
2. Die Logs richtig lesen: AVC-Denials entschlüsseln
Jede AVC-Meldung ist ein wertvoller Hinweis, aber ohne das richtige Verständnis bleibt sie ein Buch mit sieben Siegeln. Lassen Sie uns das gemeinsam knacken.
Anatomie einer AVC-Meldung
Eine typische Meldung sieht so aus:
avc: denied { read } for pid=1234 comm="httpd" path="/home/user/file.txt" dev="sda1" ino=5678 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=fileDie Bestandteile im Detail:
- `avc: denied { read }` – die Aktion, die verweigert wurde
- `pid` und `comm` – Prozess-ID und Name des ausführenden Programms
- `path` – der betroffene Dateipfad
- `scontext` – der Sicherheitskontext der Quelle (Prozess)
- `tcontext` – der Sicherheitskontext des Ziels (Datei, Port usw.)
Diese Informationen sind Gold wert. Sie zeigen genau, wer was tun wollte und warum es blockiert wurde.
Warum wird eine Aktion verweigert?
Die Verweigerung hängt von zwei Faktoren ab: den Booleans und den Dateikontexten. Ein Boolean ist ein Schalter, der bestimmte Regeln aktiviert oder deaktiviert. Der Dateikontext (Label) bestimmt, welcher Typ von Datei vorliegt. Ein Webserver (`httpd_t`) darf standardmäßig keine Dateien mit dem Label `user_home_t` lesen – das wäre ein Sicherheitsrisiko.
Praktische Übung: Fehler im Log finden
Angenommen, Ihre Webanwendung kann keine Dateien in `/home/user/uploads` schreiben. Suchen Sie gezielt nach Ablehnungen:
ausearch -m avc -ts recent | grep httpdSie sehen sofort die Meldung mit `scontext=httpd_t` und `tcontext=user_home_t`. Jetzt wissen Sie, dass der Dateikontext falsch ist.
3. Die ersten Schritte zur Konfiguration: Der Permissive-Modus
Bevor Sie Änderungen vornehmen, sollten Sie SELinux in den Permissive-Modus versetzen. Das ist wie ein Probelauf – SELinux protokolliert alles, blockiert aber nichts.
Warum der Permissive-Modus ein guter Anfang ist
Im Permissive-Modus sehen Sie, welche Aktionen blockiert würden, ohne dass Ihre Anwendung darunter leidet. Das ist ideal für die Fehlersuche. Wichtig: Deaktivieren Sie SELinux nicht komplett – das entfernt alle Labels und kann zu Inkonsistenzen führen. Ich habe diesen Fehler selbst gemacht, und glauben Sie mir, das wollen Sie nicht erleben.
Temporäre und permanente Umschaltung
Temporär schalten Sie mit `setenforce 0` um. Das hält bis zum nächsten Neustart. Für eine dauerhafte Änderung bearbeiten Sie `/etc/selinux/config` und setzen `SELINUX=permissive`. Nach einem Reboot ist die Änderung aktiv.
Logs im Permissive-Modus analysieren
Im Permissive-Modus generiert SELinux weiterhin Logs. Sie können also `ausearch -m avc -ts recent` verwenden, um zu sehen, welche Aktionen blockiert würden. Das ist perfekt, um die nächsten Schritte zu planen.
4. Richtlinien anpassen: Booleans und Dateikontexte
Jetzt wird es konkret. Sie haben die Logs analysiert und wissen, was blockiert wird. Jetzt passen Sie die Richtlinien an.
Booleans effektiv nutzen
Booleans sind Schalter, die bestimmte Regeln aktivieren oder deaktivieren. Mit `getsebool -a` listen Sie alle auf. Ein häufiges Beispiel: `httpd_can_network_connect` – damit darf der Webserver ausgehende Verbindungen aufbauen. Aktivieren Sie es mit:
setsebool -P httpd_can_network_connect onDas `-P` macht die Änderung permanent. Ohne `-P` gilt sie nur bis zum Neustart.
Dateikontexte (Labels) korrekt setzen
Mit `ls -Z` sehen Sie den Kontext einer Datei. Für dauerhafte Änderungen verwenden Sie `semanage fcontext` – nicht `chcon`. `chcon` ist nur temporär und wird beim nächsten `restorecon` überschrieben. Ich habe es oft genug erlebt, dass jemand `chcon` verwendet hat und sich wunderte, warum der Kontext nach einem Neustart weg war.
Ein Beispiel: Sie möchten, dass der Webserver auf `/home/user/uploads` zugreifen kann. Setzen Sie den Kontext mit:
semanage fcontext -a -t httpd_sys_rw_content_t "/home/user/uploads(/.*)?"Dann wenden Sie ihn an:
restorecon -Rv /home/user/uploadsFehlerbehebung bei falschen Labels
| Problem | Ursache | Lösung |
|---|---|---|
| Webserver kann nicht in /var/www/html schreiben | Falsches Label: `httpd_sys_content_t` statt `httpd_sys_rw_content_t` | Mit `semanage fcontext` und `restorecon` korrigieren |
| Anwendung kann auf /tmp nicht zugreifen | Zu restriktives Label | Booleans wie `httpd_tmp_exec` aktivieren oder Label anpassen |
5. Erweiterte Konfiguration: Eigene Richtlinienmodule erstellen
Manchmal reichen Booleans und Labels nicht aus. Dann müssen Sie ein eigenes Modul erstellen. Keine Sorge, das ist kein Hexenwerk.
Wann ist ein eigenes Modul nötig?
Wenn Ihre Anwendung eine spezielle Aktion benötigt, die durch keine Standardregel abgedeckt ist. Zum Beispiel, wenn ein Prozess eine bestimmte Datei lesen darf, aber das Label nicht geändert werden soll.
Der Weg zum eigenen Modul
- Fehler im Log identifizieren: `ausearch -m avc -ts recent`
- Fehlerdatei generieren: `ausearch -m avc -ts recent > /tmp/avc.txt`
- Modulvorschlag generieren: `audit2allow -M mein_modul < /tmp/avc.txt`
- Modul aktivieren: `semodule -i mein_modul.pp`
- Prüfen, ob der Fehler behoben ist: `ausearch -m avc -ts recent`
Das erzeugt ein Modul, das genau die benötigten Rechte vergibt. Aber Vorsicht: `audit2allow` neigt dazu, zu viele Rechte zu vergeben. Überprüfen Sie die `.te`-Datei und schränken Sie die Regeln manuell ein. Das ist ein wichtiger Sicherheitsaspekt.
Sicherheitsaspekte bei eigenen Modulen
Ein eigenes Modul kann ein Sicherheitsrisiko darstellen, wenn es zu großzügig ist. Beschränken Sie die Regeln auf das Minimum. Ich habe schon Module gesehen, die dem Prozess alle Rechte auf dem gesamten System gaben – das ist ein Albtraum. Also: Nachbearbeiten ist Pflicht.
6. Häufige Fehler vermeiden
Aus meiner Erfahrung gibt es vier typische Fehler, die immer wieder auftreten. Vermeiden Sie sie, dann sind Sie auf der sicheren Seite.
Fehler 1: SELinux komplett deaktivieren
Das ist der häufigste Fehler. SELinux zu deaktivieren, reduziert die Sicherheit drastisch. In Unternehmensumgebungen, die DSGVO-konform arbeiten müssen, ist das ein No-Go. Ich rate dringend davon ab.
Fehler 2: Den Permissive-Modus als Dauerlösung nutzen
Der Permissive-Modus ist nur zur Fehlersuche gedacht. Wenn Sie ihn dauerhaft aktivieren, haben Sie den Schutz von SELinux nicht. Schalten Sie nach der Fehlerbehebung wieder auf Enforcing um.
Fehler 3: `chcon` für dauerhafte Änderungen verwenden
Wie bereits erwähnt, ist `chcon` temporär. Verwenden Sie immer `semanage fcontext` und `restorecon`. Sonst verlieren Sie den Kontext beim nächsten Dateisystem-Check.
Fehler 4: Logs ignorieren
Die Logs sind Ihre beste Informationsquelle. Ignorieren Sie sie nicht. Richten Sie ein Monitoring für `/var/log/audit/audit.log` ein, zum Beispiel mit `logwatch` oder `auditd`. So bleiben Sie über verdächtige Aktivitäten informiert.
7. Häufig gestellte Fragen (FAQ)
Wie kann ich den SELinux-Status schnell prüfen?
Mit `getenforce` sehen Sie sofort, ob SELinux aktiv ist und in welchem Modus. Das ist der schnellste Weg.
Was ist der Unterschied zwischen `chcon` und `semanage fcontext`?
`chcon` ändert den Kontext direkt auf der Datei, aber nur temporär. `semanage fcontext` ändert die Regel in der SELinux-Policy, und die Änderung bleibt dauerhaft erhalten.
Meine Anwendung wird blockiert, aber das Log zeigt nichts. Warum?
Prüfen Sie, ob `auditd` läuft: `systemctl status auditd`. Wenn nicht, starten Sie es. Oder schauen Sie in `/var/log/messages` – dort landen manchmal SELinux-Meldungen, wenn das Audit-System nicht aktiv ist.
Ist SELinux auch für Desktop-Systeme relevant?
Ja, besonders für Laptops mit sensiblen Daten. Die Konfiguration ist ähnlich, aber die Logs sind oft weniger aktiv. Trotzdem schadet es nicht, SELinux zu aktivieren.
Gibt es grafische Tools zur Verwaltung?
Ja, zum Beispiel `system-config-selinux` (veraltet) oder `setroubleshoot`. Mit `sealert -a /var/log/audit/audit.log` erhalten Sie verständliche Vorschläge auf Deutsch oder Englisch. Das hilft enorm bei der Fehlerbehebung.
Fazit: Mit den richtigen Kenntnissen wird SELinux zur starken Verteidigungslinie
Sie haben jetzt das Rüstzeug, um SELinux-Richtlinien zu verstehen und zu konfigurieren. Der Dreiklang aus `ausearch`, `audit2allow` und `semanage` führt Sie sicher zum Ziel. SELinux ist keine Blackbox mehr – es ist ein mächtiges Werkzeug, das Ihre Systeme schützt.
Ich hoffe, dieser Leitfaden hat Ihnen geholfen. Wenn Sie Fragen haben, stellen Sie sie in den Kommentaren. Und teilen Sie diesen Artikel mit Ihrem Team – je mehr Leute SELinux verstehen, desto sicherer sind unsere Systeme.
Jetzt ist Ihr System sicher konfiguriert. Teilen Sie diesen Leitfaden mit Ihrem Team oder speichern Sie ihn für das nächste Troubleshooting!
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
