Die klassischen Dateirechte bestimmen, welche Zugriffe ein Benutzer oder ein Prozess anhand seiner Benutzerkennung, Gruppen und Berechtigungen ausführen darf. Trotzdem kann ein Zugriff scheitern, obwohl Eigentümer, Gruppenrechte und ACLs korrekt erscheinen.
Eine mögliche Ursache ist SELinux: eine zusätzliche Sicherheitsprüfung, die Zugriffe anhand einer systemweiten Richtlinie bewertet. Erlaubte Dateirechte genügen dann nicht allein. Auch die SELinux-Richtlinie muss den vorgesehenen Zugriff zulassen.
Dabei geht es nicht nur darum, wer einen Prozess ausführt. Entscheidend ist auch, in welchem Sicherheitskontext der Prozess arbeitet und wie die angefragte Ressource eingeordnet ist.
Warum klassische Dateirechte nicht jede Sicherheitsfrage lösen
Ein Webserver benötigt Zugriff auf die Dateien, die er ausliefern soll. Gleichzeitig sollte er möglichst keine privaten Benutzerdaten oder fremden Dienstkonfigurationen lesen können.
Mit klassischen Dateirechten lässt sich bereits viel davon abbilden. Allerdings können Dateien aus anderen Gründen für mehrere Benutzer lesbar sein. Ein Dienst könnte dadurch mehr lesen dürfen, als für seine eigentliche Aufgabe erforderlich ist.
SELinux ergänzt deshalb eine weitere Frage:
Darf ein Prozess dieser sicherheitsrelevanten Einordnung überhaupt auf eine Ressource dieser Art zugreifen?
Die sogenannte Type-Enforcement-Richtlinie kann beispielsweise einen Webserverprozess auf die für ihn vorgesehenen Dateitypen begrenzen. Dass seine Linux-Benutzerkennung eine Datei lesen dürfte, reicht dann nicht aus.
Zwei Prüfungen, die zusammenpassen müssen
Die klassische Rechteverwaltung wird als Discretionary Access Control, kurz DAC, bezeichnet. SELinux ergänzt sie um Mandatory Access Control, kurz MAC: eine verbindliche, zentral vorgegebene Zugriffskontrolle.
Vereinfacht ergibt sich bei einem Dateizugriff folgendes Modell:
Ein Prozess möchte eine Datei lesen
│
▼
Erlauben die klassischen Zugriffsregeln den Zugriff?
│
nein ───┴─── ja
│ │
▼ ▼
Zugriff Erlaubt die SELinux-
verweigert Richtlinie den Zugriff?
│
nein ───┴─── ja
│ │
▼ ▼
Zugriff Zugriff aus Sicht
verweigert dieser Prüfungen erlaubtSELinux ersetzt die gewöhnlichen Rechte nicht und erteilt auch keine Ausnahme von ihnen. Wenn bereits die klassische Prüfung scheitert, wird der Zugriff abgewiesen; dafür muss keine SELinux-Verweigerung im Protokoll entstehen.
Weitere Einschränkungen, etwa ein schreibgeschützter Mount, können unabhängig davon hinzukommen.
Was ist ein SELinux-Kontext?
Ein Sicherheitskontext ist eine Kennzeichnung, die SELinux für Zugriffsentscheidungen verwendet. Sowohl Prozesse als auch Dateien besitzen solche Kontexte.
Ein Dateikontext kann beispielsweise so aussehen:
system_u:object_r:httpd_sys_content_t:s0Die Bestandteile haben unterschiedliche Aufgaben:
| Bestandteil | Beispiel | Bedeutung |
|---|---|---|
| SELinux-Benutzer | system_u | Benutzerzuordnung innerhalb des SELinux-Modells; nicht mit der Linux-UID gleichzusetzen |
| Rolle | object_r | Rollenbestandteil; bei Dateien typischerweise diese Objektrolle |
| Typ | httpd_sys_content_t | Sicherheitsrelevante Einordnung, beispielsweise als Webinhalt |
| Sicherheitsstufe beziehungsweise Bereich | s0 | Einordnung für zusätzliche Stufen- und Kategorienmodelle |
In einer üblichen „targeted“-Richtlinie ist für viele alltägliche Administrationsaufgaben besonders der Typ wichtig. Die übrigen Bestandteile sind dadurch aber nicht grundsätzlich bedeutungslos.
Ein Kontext ist keine Liste von Zugriffsrechten. Er liefert die Einordnung, auf deren Grundlage die Richtlinie entscheidet.
Prozesstyp und Dateityp: Die Beziehung entscheidet
Bei Prozessen wird der Typ häufig als Domain bezeichnet. Ein typisches Beispiel aus der mitgelieferten Webserver-Richtlinie ist:
| Objekt | Typ beziehungsweise Domain |
|---|---|
| Webserverprozess | httpd_t |
| Statische Webinhalte | httpd_sys_content_t |
Die Richtlinie kann festlegen, dass Prozesse in der Domain httpd_t Dateien vom Typ httpd_sys_content_t lesen dürfen. Schreiben ist damit nicht automatisch erlaubt.
Die Prüfung berücksichtigt außerdem, um welche Objektart und welchen Vorgang es geht. Ein Verzeichnis durchsuchen, eine Datei lesen und eine Datei verändern sind unterschiedliche Berechtigungen.
Die zentrale Beziehung lautet daher:
Welche Prozess-Domain darf welche Operation auf welcher Art von Zielobjekt ausführen?
Der Dateityp allein sagt nicht, dass eine Datei für alle Prozesse lesbar oder schreibbar ist. Seine Bedeutung entsteht durch die Regeln, die ihn mit den jeweiligen Prozess-Domains verbinden.
Beispiel: Eine Webseite mit dem falschen Kontext
Angenommen, eine HTML-Datei liegt im Webverzeichnis. Der Webserver besitzt nach den klassischen Dateirechten Leserecht. Trotzdem kann SELinux den Zugriff verweigern, wenn die Datei beispielsweise als privater Benutzerinhalt mit user_home_t statt als Webinhalt eingeordnet ist.
Für gewöhnliche statische Webinhalte ist in der entsprechenden Richtlinie dagegen häufig httpd_sys_content_t vorgesehen. Die Red-Hat-Dokumentation zeigt genau diesen Fall: restorecon korrigiert eine Datei unter /var/www/html/ von user_home_t auf den vorgesehenen Webinhaltstyp.
Wichtig ist die Folgerung: Der Dateiname und der sichtbare Ablageort allein garantieren noch keinen passenden aktuellen Kontext.
Eine HTML-Datei wird nicht deshalb automatisch zugänglich, weil sie auf .html endet. Entscheidend ist die tatsächlich wirksame Kennzeichnung in Verbindung mit der Richtlinie.
Enforcing, Permissive und Disabled
Für die Einordnung von Fehlern ist der Betriebszustand entscheidend:
| Zustand | Verhalten |
|---|---|
| Enforcing | SELinux setzt die Richtlinie durch und verhindert nicht erlaubte Zugriffe |
| Permissive | SELinux bewertet Zugriffe und protokolliert entsprechende Verweigerungen, blockiert sie aber nicht selbst |
| Disabled | SELinux ist deaktiviert; die zusätzliche Prüfung findet nicht statt |
Permissive bedeutet nicht, dass jetzt jeder Zugriff erlaubt ist. Die klassischen Dateirechte und andere Schutzmechanismen bleiben weiterhin wirksam. Lediglich die SELinux-Richtlinie wird nicht durchgesetzt.
Auch ist Permissive nicht gleichbedeutend mit Disabled: Die weiterhin stattfindende Bewertung und Protokollierung macht den Permissive-Modus für die Diagnose interessant.
Den aktuellen Modus zeigt:
getenforceDie ausführlichere Übersicht liefert:
sestatusDiese Zustandsprüfung gehört an den Anfang einer SELinux-Diagnose.
Kontexte von Dateien und Prozessen anzeigen
Bei der Fehlersuche müssen beide Seiten betrachtet werden: die Ressource und der zugreifende Prozess.
Dateikontext prüfen
ls -Z /var/www/html/index.htmlMit zusätzlichen Dateiinformationen:
ls -lZ /var/www/html/index.htmlFür das Verzeichnis selbst:
ls -Zd /var/www/htmlDie Ausgabe zeigt den aktuellen Sicherheitskontext des jeweiligen Objekts.
Prozesskontext prüfen
ps -eZDamit lässt sich erkennen, in welchen SELinux-Kontexten die laufenden Prozesse arbeiten. Gerade der Prozesstyp ist wichtig, weil die Richtlinie ihre Regeln nicht allein an den Programmnamen oder die Linux-Benutzerkennung knüpft.
Die Beispiele orientieren sich an SELinux-Systemen mit den entsprechenden Werkzeugen und Richtlinien, etwa aus dem Fedora-/RHEL-Umfeld. Welche Dienste und Typen vorhanden sind, hängt von der installierten Richtlinie ab.
Aktuelle Kennzeichnung und vorgesehene Kennzeichnung unterscheiden
Für die Verwaltung ist eine Unterscheidung besonders wichtig:
- Der aktuelle Kontext ist die Kennzeichnung, die ein Objekt momentan trägt.
- Die Dateikontext-Konfiguration beschreibt, welche Kennzeichnung für einen Pfad vorgesehen ist.
Diese beiden Zustände müssen nicht übereinstimmen.
Die Werkzeuge übernehmen deshalb unterschiedliche Aufgaben:
| Werkzeug | Aufgabe |
|---|---|
chcon | Den aktuellen Kontext eines Objekts verändern |
semanage fcontext | Dauerhafte pfadbezogene Zuordnungen in der Dateikontext-Konfiguration verwalten |
restorecon | Die vorgesehenen Kontexte auf vorhandene Objekte anwenden |
Ein Aufruf von semanage fcontext allein beschriftet die vorhandenen Dateien noch nicht neu. Erst restorecon wendet die konfigurierte Zuordnung an.
Warum chcon allein oft nicht die dauerhafte Lösung ist
Eine Änderung mit chcon kann zunächst funktionieren. Sie verändert aber nicht die zugrunde liegende pfadbezogene Vorgabe.
Ein späterer restorecon-Lauf oder eine vollständige Neuetikettierung kann diese manuelle Änderung deshalb wieder überschreiben. Für einen dauerhaft abweichenden Ablageort ist die Kombination aus semanage fcontext und restorecon vorgesehen.
Beispiel: Ein eigenes Verzeichnis für statische Webseiten
Soll ein Dienst statische Inhalte aus /srv/myweb ausliefern, muss neben der Dienstkonfiguration und den klassischen Dateirechten auch die SELinux-Einordnung passen.
Für die entsprechende Webserver-Richtlinie zeigt die Dokumentation dieses Vorgehen:
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/myweb(/.*)?'
sudo restorecon -Rv /srv/mywebDer erste Befehl hinterlegt die gewünschte Zuordnung für das Verzeichnis und seine Unterpfade. Der zweite wendet sie auf die vorhandenen Objekte an.
Das Beispiel gilt für statische Webinhalte. Es erlaubt dem Webserver nicht automatisch das Schreiben und passt auch nicht pauschal für jede Webanwendung.
Die eigentliche Aufgabe lautet nicht „irgendeinen funktionierenden Typ setzen“, sondern den Typ wählen, der zur vorgesehenen Nutzung passt.
Eine Verweigerung ist ein Diagnosehinweis
SELinux-Verweigerungen erscheinen häufig als sogenannte AVC-Meldungen. AVC steht für Access Vector Cache, den Zwischenspeicher für Zugriffsentscheidungen.
Auf entsprechend konfigurierten Systemen ist das Audit-Protokoll eine zentrale Informationsquelle. Aktuelle Meldungen lassen sich beispielsweise so suchen:
sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recentDie Meldungen helfen zu erkennen, welcher Prozess auf welches Ziel zugreifen wollte und welche Operation betroffen war.
Eine Verweigerung kann unterschiedliche Ursachen haben:
- Eine Datei trägt einen unpassenden Kontext.
- Ein Dienst verwendet einen neuen Ablageort.
- Eine vorgesehene Richtlinienoption ist nicht aktiviert.
- Ein Dienst nutzt einen Port, dessen SELinux-Zuordnung nicht passt.
- Der Zugriff liegt tatsächlich außerhalb dessen, was dem Dienst erlaubt sein soll.
Booleans: Vorgesehene Richtlinienoptionen statt beliebiger Freigaben
Manche Richtlinien bieten sogenannte Booleans. Damit lassen sich vorgesehene Verhaltensvarianten aktivieren oder deaktivieren, ohne eine eigene Richtlinie zu schreiben.
Solche Optionen können beispielsweise beeinflussen, welche zusätzlichen Funktionen ein Dienst nutzen darf. Die Dokumentation nennt Booleans neben Dateikennzeichnungen und Portzuordnungen als wichtigen Prüfpunkt bei Problemen.
Auch hier gilt: Eine Option sollte aktiviert werden, weil der Dienst diese Fähigkeit benötigt – nicht lediglich, weil dadurch eine Fehlermeldung verschwindet.
Dasselbe gilt für automatisch erzeugte Freigaberegeln. Vor einer Erweiterung der Richtlinie sollten zunächst falsche Kontexte und nicht berücksichtigte Konfigurationsänderungen ausgeschlossen werden.
Was SELinux nicht ersetzt
SELinux bildet eine zusätzliche Schutzschicht, kein vollständiges Sicherheitskonzept.
Insbesondere ersetzt es nicht:
- Eine sinnvolle Vergabe klassischer Dateirechte.
- Die Trennung von Dienstkonten.
- Eine sichere Dienstkonfiguration.
- Das Schließen von Sicherheitslücken.
- Die Prüfung, welche Daten ein Dienst für seine Aufgabe tatsächlich benötigt.
Wie stark ein Prozess eingeschränkt ist, hängt außerdem von seiner Domain und der geladenen Richtlinie ab. Die Aussage „SELinux ist aktiv“ bedeutet deshalb nicht automatisch, dass jeder Prozess gleich streng isoliert ist. Die Dokumentation unterscheidet ausdrücklich zwischen eingeschränkten und weitgehend uneingeschränkten Domains.
Der praktische Nutzen liegt darin, die Handlungsmöglichkeiten eines Dienstes zusätzlich zu begrenzen. Auch ein fehlgeleiteter Prozess soll möglichst nicht auf alle Ressourcen zugreifen können, die seine Linux-Benutzerkennung grundsätzlich erreichen könnte.
Fazit: Nicht nur die Rechte, sondern auch die Einordnung zählt
Bei SELinux müssen klassische Zugriffsrechte und Sicherheitsrichtlinie zusammenpassen. Prozesse und Ressourcen tragen Kontexte; besonders ihre Typen bestimmen in üblichen Richtlinien, welche Beziehungen und Operationen erlaubt sind.
Scheitert ein Zugriff trotz scheinbar passender Dateirechte, gehört deshalb auch SELinux zur Diagnose: Welcher Prozess greift zu, welchen Kontext trägt das Ziel, und erlaubt die Richtlinie genau diesen Vorgang?
Die passende Lösung besteht dann nicht automatisch in großzügigeren Dateirechten oder dem Abschalten von SELinux. Häufig müssen lediglich die Kennzeichnung, der vorgesehene Ablageort und die Dienstkonfiguration wieder miteinander in Einklang gebracht werden.
