SELinux-Zugriffe untersuchen: vom AVC-Eintrag zur Label-Reparatur

Nach dem Verschieben der Website-Dateien aus dem ursprünglichen Verzeichnis nach /srv liefert httpd einen Fehler 403. Die Dateien sind lesbar, und der Dienst läuft. Trotzdem sollten Sie jetzt weder pauschal die Berechtigungen erweitern noch SELinux deaktivieren. Klassische Dateirechte, die Autorisierung in der Dienstkonfiguration und die verpflichtende Zugriffskontrolle sind drei getrennte Prüfebenen. Anhand eines bereits eingerichteten httpd-Test-VirtualHosts unter AlmaLinux 9 ordnen wir dem fehlgeschlagenen Request die passenden AVC-Einträge zu, korrigieren die Labels dauerhaft und prüfen anschließend den Dienst sowie die Zugriffsgrenzen.

1. Testumfang festlegen und Ausgangszustand dokumentieren

Für einen Dedicated Server von CloudDDR können Sie AlmaLinux 9 auswählen. Nach der Zahlung finden Sie die Zugangsdaten im Control Panel und können sich per SSH verbinden. Sind mehrere Adressen vorhanden, verwenden Sie die erste. Die folgenden Schritte erfordern Administratorrechte und dürfen nur in einer isolierten Testumgebung ausgeführt werden. Überschreiben Sie keine bestehenden produktiven Verzeichnisse und ändern Sie weder die Listen-Adressen noch die Firewall.

Vorausgesetzt wird, dass httpd bereits installiert ist und der Test-VirtualHost samt Zugangsadresse eingerichtet wurde. Sichern Sie zunächst dessen Konfiguration und notieren Sie den ursprünglichen DocumentRoot. Falls Diagnosewerkzeuge fehlen, installieren Sie das entsprechende Paket. Prüfen Sie danach den Sicherheitsmodus und den Audit-Dienst:

sudo dnf install policycoreutils-python-utils
getenforce
sestatus
sudo systemctl status auditd --no-pager
sudo semanage fcontext -l -C
sudo semanage permissive -l

Der globale Modus sollte Enforcing sein. Auch die Domain, in der httpd läuft, darf nicht separat auf permissive gesetzt sein. Funktioniert der Audit-Dienst nicht ordnungsgemäß, stellen Sie zuerst die Erfassung der Diagnosedaten wieder her. Fehlende Ablehnungseinträge im Protokoll sind kein Beleg dafür, dass der Zugriff nicht eingeschränkt wird. Speichern Sie die Liste der lokalen Label-Zuordnungen, damit Sie später bestehende Regeln von den im Test neu angelegten Regeln unterscheiden können.

setenforce 0 ist keine Reparatur. Gelingt der Request nach dem Abschalten der erzwungenen Kontrolle, liefert das lediglich einen Hinweis für die Fehlersuche. Es beweist nicht, dass der Zugriff nach der Rückkehr zu enforcing weiterhin funktioniert.

2. Zuerst klassische Berechtigungs- und Konfigurationsfehler ausschließen

Legen Sie ein eigenes Testverzeichnis an. Die Testdatei enthält lediglich eine Zeile als Prüfmarker. Das Verzeichnis muss durchsuchbar und die Datei lesbar sein. Diese Berechtigungen gelten nur für öffentliches Testmaterial, nicht für Schlüssel, Backups oder produktive Daten.

sudo install -d -m 0755 /srv/selinux-lab
printf 'selinux-lab-ok\n' | sudo tee /srv/selinux-lab/index.html
sudo chmod 0644 /srv/selinux-lab/index.html
namei -l /srv/selinux-lab/index.html
ls -ldZ /srv/selinux-lab
ls -lZ /srv/selinux-lab/index.html

Ändern Sie im bestehenden Test-VirtualHost das Dokumentenverzeichnis und die zugehörige Verzeichnisfreigabe wie folgt:

DocumentRoot "/srv/selinux-lab"

<Directory "/srv/selinux-lab">
    AllowOverride None
    Options -Indexes
    Require all granted
</Directory>

Prüfen Sie vor der Änderung, welche Konfigurationsdateien eingebunden werden und wie sie zusammenwirken, damit kein anderer Verzeichnisabschnitt die Freigabe überschreibt. Kontrollieren Sie die Syntax mit httpd -t und prüfen Sie mit httpd -S, ob der Request den vorgesehenen VirtualHost erreicht. Laden Sie die Konfiguration erst nach erfolgreichen Prüfungen neu.

Setzen Sie die Shell-Variable CHECK_URL auf die tatsächliche Testadresse mit dem Pfad /index.html. Die Adresse muss zum VirtualHost passen. Schreiben Sie keine Zugangsdaten in die URL. Prüfen Sie beim Request den Antwortinhalt und nicht nur, ob die Verbindung zustande kommt:

sudo httpd -t
sudo httpd -S
sudo systemctl reload httpd
curl --fail --show-error "$CHECK_URL"

Schlägt der Request fehl, lesen Sie zunächst das httpd-Fehlerprotokoll. Ein fehlendes Ausführungsrecht auf einem übergeordneten Verzeichnis, der falsche VirtualHost oder eine verweigernde Autorisierungsregel können ähnliche Symptome verursachen. Eine rekursive Erweiterung der Berechtigungen behebt dann weder ein Label-Problem noch bleibt sie ohne Folgen: Sie vergrößert den zugänglichen Bereich.

3. Subjekt, Objekt und Aktion anhand von AVC bestimmen

Notieren Sie den Zeitpunkt des Requests, reproduzieren Sie den fehlgeschlagenen Vorgang genau einmal und suchen Sie anschließend nach Ablehnungseinträgen aus demselben Zeitraum:

sudo ausearch -m AVC,USER_AVC -ts recent -i
ps -eZ | grep '[h]ttpd'
matchpathcon -V /srv/selinux-lab/index.html

Achten Sie im AVC besonders auf scontext, tcontext, tclass und die verweigerten Zugriffsrechte. scontext bezeichnet die Domain des zugreifenden Prozesses, tcontext den Sicherheitskontext des Zielobjekts. Das Lesen einer Datei und das Durchsuchen eines Verzeichnisses sind unterschiedliche Aktionen. Der Prozessname allein reicht daher nicht für eine Bewertung aus.

Ordnen Sie Pfad, Prozess und Zeitpunkt des Eintrags dem fehlgeschlagenen Request zu. Wird das Durchsuchen eines Verzeichnisses verweigert, müssen Sie auch sämtliche Verzeichnisse entlang des Pfads prüfen. Nur die Zieldatei zu korrigieren, kann wirkungslos bleiben. Enthält der Protokolleintrag keinen Pfad, können Sie über die Audit-Ereignisnummer weitere Einträge desselben Ereignisses heranziehen.

Das Fehlen von AVC-Einträgen schließt einen Zusammenhang nicht sicher aus. Prüfen Sie zuerst den Zeitraum, den Audit-Status und die tatsächliche Prozess-Domain des Dienstes. Finden Sie weiterhin keine passenden Belege, kehren Sie zur Anwendungskonfiguration und zu den klassischen Berechtigungen zurück, statt auf Verdacht erlaubende Regeln hinzuzufügen. Übergeben Sie auch nicht sämtliche älteren Ablehnungseinträge an ein Werkzeug zur Policy-Erzeugung: Sie können von anderen Diensten stammen.

4. Labels für Webinhalte dauerhaft korrigieren

Für gewöhnliche statische Inhalte, die httpd lesen soll, sieht die bestehende Policy den Typ httpd_sys_content_t vor. Legen Sie eine präzise Zuordnung nur dann an, wenn die Diagnosedaten zeigen, dass die Labels des Testpfads nicht zu seinem Verwendungszweck passen:

sudo semanage fcontext -a -t httpd_sys_content_t \
    '/srv/selinux-lab(/.*)?'
sudo restorecon -Rv /srv/selinux-lab
matchpathcon -V /srv/selinux-lab/index.html
ls -lZ /srv/selinux-lab/index.html

Existiert bereits genau derselbe Ausdruck, prüfen Sie die ursprüngliche Regel und ändern Sie sie bei Bedarf mit -m, statt weitere Regeln hinzuzufügen. Der Ausdruck darf nur das Testverzeichnis erfassen, nicht das gesamte /srv zum Webinhalt erklären. semanage speichert die Zuordnung zwischen Pfad und Typ. Erst restorecon wendet den vorgesehenen Kontext auf vorhandene Dateien an.

chcon verändert das aktuelle Label direkt, legt aber keine dauerhafte Zuordnung an und ersetzt diesen Schritt deshalb nicht. Eine spätere Neulabelung kann die vorübergehende Änderung wieder aufheben.

Für ein statisches Verzeichnis benötigt der Dienst keine Schreibrechte. Stellen Sie nicht sämtliche Inhalte auf einen schreibbaren Typ um, nur um eine einzelne Ablehnung zu beseitigen. Aktivieren Sie auch keine unbeteiligten Booleans nebenbei. Sind tatsächlich Schreibzugriffe für Uploads, Caches oder ähnliche Zwecke nötig, richten Sie dafür ein separates Verzeichnis ein und planen Sie dessen Berechtigungen und Labels anhand der tatsächlich benötigten Aktionen.

5. Ergebnis prüfen und Rückweg offenhalten

Lassen Sie enforcing aktiv und rufen Sie dieselbe Adresse erneut auf. Prüfen Sie, ob der Antwortinhalt selinux-lab-ok enthält und ob neue AVC-Einträge entstanden sind, die zu diesem Request gehören. Führen Sie anschließend erneut restorecon aus, starten Sie den Testdienst neu und wiederholen Sie den Request. So prüfen Sie, ob die Reparatur unabhängig von vorübergehenden Labels oder dem bisherigen Prozesszustand funktioniert.

getenforce
sudo restorecon -Rv /srv/selinux-lab
sudo systemctl restart httpd
curl --fail --show-error "$CHECK_URL"
sudo ausearch -m AVC,USER_AVC -ts recent -i

Zur Abnahme gehören auch Negativprüfungen: Der Abruf einer nicht vorhandenen Datei muss fehlschlagen; das Testverzeichnis darf keine Verzeichnisauflistung erlauben; der Dienst darf keine zusätzlichen, unerwarteten Listen-Adressen oder Ports verwenden; lokale Label-Änderungen müssen auf den vereinbarten Pfad beschränkt bleiben. Diese Prüfungen kontrollieren jeweils das Anwendungsverhalten, die Konfiguration und den Änderungsumfang. Sie ersetzen einander nicht.

Stellen Sie zum Abschluss des Experiments zuerst die ursprüngliche VirtualHost-Konfiguration wieder her, prüfen Sie die Syntax und laden Sie die Konfiguration neu. Entfernen Sie erst danach das Testverzeichnis. Eine Zuordnung, die in diesem Experiment tatsächlich neu angelegt wurde, kann gelöscht werden. Wurde eine bestehende Zuordnung geändert, stellen Sie den zuvor dokumentierten Typ wieder her. Führen Sie nach der Bereinigung restorecon für die verbleibenden Pfade aus.

Bewahren Sie abschließend den fehlgeschlagenen Request, die zugehörigen AVC-Einträge, die Labels vor und nach der Änderung, den Zuordnungsausdruck und das Antwortergebnis nach dem Neustart auf. Ein einzelner erfolgreicher Request belegt nur, dass die Funktion wiederhergestellt ist. Vollständig abgenommen ist die Reparatur erst, wenn der Sicherheitsmodus unverändert bleibt, die Labels anhand der Zuordnung wiederhergestellt werden können und der Zugriffsbereich nicht erweitert wurde.

Häufig gestellte Fragen