Linux/SELinux/Praxis/2: Unterschied zwischen den Versionen

Versionsgeschichte interaktiv durchsuchen

Aktuelle Version vom 27. März 2026, 23:09 Uhr

Woher kommt der „richtige“ Kontext (File Contexts)

In der ersten Phase wurden die tatsächlichen Dateilabels betrachtet: was in security.selinux gespeichert ist, wie dies in ls -Z aussieht und warum sich cp und mv unterschiedlich verhalten

In dieser Lektion kommt die nächste Modellebene hinzu: SELinux speichert nicht nur das aktuelle Label eines Objekts, sondern auch die Vorstellung davon, welcher Kontext einem Pfad gemäß den Regeln der Policy zugewiesen sein soll Für das Verständnis der Logik der SELinux-Labeling-Regeln müssen zwei Begriffe strikt voneinander getrennt werden

Tatsächliches Label (Security Context). Das sind die Daten, die physisch in den erweiterten Attributen des Dateisystems (extended attributes — xattr) auf dem Datenträger gespeichert sind
- Genau dieses Label sehen der Linux-Kernel und das SELinux-Modul beim Zugriff auf eine Datei und verwenden es für die Zugriffsentscheidung
Erwarteter Kontext (File Context). Das ist eine Regel, die in der SELinux-Policy-Datenbank definiert ist
- Sie legt fest, welches Label einer Datei oder einem Verzeichnis an einem bestimmten Pfad zugewiesen werden soll

Wo SELinux Informationen über erwartete Kontexte speichert

In der Default-Policy befinden sich die Änderungen im Zusammenhang mit File Contexts im Verzeichnis

/etc/selinux/default/contexts/files/

Die aktuelle Policy kann mit dem Befehl sestatus angezeigt werden

# sestatus
..
SELinux root directory:         /etc/selinux
Loaded policy name:             default
..

Struktur der File-Context-Dateien

file_contexts — Basistabelle der File Contexts der aktiven Policy
file_contexts.local — lokale administrative Ergänzungen
file_contexts.homedirs — separate Einstellungen für Home-Verzeichnisse
.subs und .subs_dist — Dateien für Pfadsubstitutionen

Um zu verstehen, wie das System Pfade und Labels einander zuordnet, öffnen wir die Datei /etc/selinux/default/contexts/file/file_contexts

head /etc/selinux/default/contexts/files/file_contexts

Ausgabe

/.*                               system_u:object_r:default_t:s0
/a?quota\.(user|group)    --      system_u:object_r:quota_db_t:s0
/sys(/.*)?                        system_u:object_r:sysfs_t:s0
/xen(/.*)?                        system_u:object_r:xen_image_t:s0
/mnt(/[^/]*)   			      -l      system_u:object_r:mnt_t:s0
/mnt(/[^/]*)?   		        -d      system_u:object_r:mnt_t:s0
/dev/.*                           system_u:object_r:device_t:s0
/etc/.*                           system_u:object_r:etc_t:s0
/opt/.*                           system_u:object_r:usr_t:s0
/run/.* 						                <<none>>

Jede Zeile in dieser Datei stellt eine feste Anweisung für SELinux dar und besteht aus zwei oder drei Spalten

Regulärer Ausdruck (Regular Expression). Die erste Spalte beschreibt den Pfad
- SELinux verwendet reguläre Ausdrücke im PCRE*-Format
- Beispielsweise bedeutet der Ausdruck /var/www(/.*)?: sowohl das Verzeichnis /var/www selbst als auch absolut jede Datei oder jedes Unterverzeichnis darin
- Ausführlicher über reguläre Ausdrücke sprechen wir in den nächsten Lektionen
Objekttyp (optional). Die zweite Spalte kann präzisieren, für welchen Typ von Dateisystemobjekten die Regel gilt
- -d — nur auf Verzeichnisse anwenden
- -- — nur auf reguläre Dateien anwenden
- Falls die Spalte fehlt, gilt die Regel für alle Objekte am angegebenen Pfad.
Erwarteter Kontext (Security Context). Die letzte Spalte enthält das Referenzlabel, das dem Objekt zugewiesen werden soll
- Das wichtigste Element hierbei ist Type (zum Beispiel httpd_sys_content_t), der die Zugriffsdomänen bestimmt

(* PCRE - Perl-compatible regular expression)

Bei der Initialisierung des Dateisystems oder beim erzwungenen Zurücksetzen der Labels (Relabeling) liest der Kernel diese Datei Zeile für Zeile von oben nach unten

Wenn das Dienstprogramm eine Übereinstimmung zwischen dem Dateipfad und dem regulären Ausdruck findet, weist es dem Objekt den entsprechenden Kontext aus der dritten Spalte zu

Struktur von File-Context-Regeln und ihre Prioritäten

Im vorherigen Schritt wurde die Quelle der Dateikontexte analysiert — die Datenbank file_contexts

In dieser Lektion gehen wir tiefer in die Funktionsweise dieser Datenbank: wie das System die Zuordnungstabelle path -> label genau liest und wie es entscheidet, welcher Kontext zugewiesen wird, wenn mehrere Regeln auf denselben Pfad passen

Format einer File-Context-Regel

Jeder Eintrag in file_contexts, file_contexts.local und file_contexts.homedirs hat dieselbe Grundform

pathname [file_type] context

pathname — vollständiger Pfad oder regulärer PCRE-Ausdruck, anhand dessen SELinux nach Übereinstimmungen sucht
file_type — optionale Einschränkung auf einen Objekttyp
context — der Kontext, der dem Objekt zugewiesen werden soll

pathname

Betrachten wir ein Beispiel für eine Regel

/var/www(/.*)?    system_u:object_r:httpd_sys_content_t:s0

Die Regel deckt den gesamten Teilbaum /var/www ab, also das Verzeichnis selbst und alle darin enthaltenen Objekte

file_type

Die optionale zweite Spalte schränkt die Regel auf einen bestimmten Objekttyp ein

In File Contexts werden folgende Bezeichnungen verwendet

Wert	Beschreibung
d	Verzeichnis
-	reguläre Datei
l	symbolischer Link
s	Socket
p	Named Pipe
c	Zeichengerätedatei
b	Blockgerätedatei

context

Die letzte Spalte enthält genau den erwarteten Security Context, der für einen übereinstimmenden Pfad zurückgegeben werden soll

Im Normalfall ist das ein vollständiges Label im Format user:role:type:range

Zulässig ist auch der spezielle Wert <<none>>

Er bedeutet, dass beim Relabeling für den übereinstimmenden Pfad kein Kontext gesetzt werden soll und dass ein Lookup kein Ergebnis zurückliefert

Prioritäten der Regeln

Basis- und modulare Policy-Definitionen

Um Konflikte zu vermeiden, verwendet der SELinux-Parser ein striktes Prioritätssystem

Eine exakte Übereinstimmung hat die höchste Priorität. Eine Regel, die einen Pfad ohne Platzhalter regulärer Ausdrücke beschreibt (zum Beispiel genau /etc/passwd), gewinnt immer gegenüber allgemeineren Ausdrücken
Die maximale Länge der Übereinstimmung bestimmt die Spezifität. Falls es keine exakte Übereinstimmung gibt, gewinnt die spezifischste Regel — also diejenige, bei der der übereinstimmende Teil des Pfads länger ist
- Eine Regel für /var/www/html(/.*)? sticht eine allgemeinere Regel für /var/www(/.*)?
Eine explizite Angabe der Objektklasse erhöht die Priorität. Bei gleicher Länge der Übereinstimmung hat eine Regel mit explizit angegebenem Klassifizierer (zum Beispiel -d für Verzeichnisse oder -- für reguläre Dateien) Vorrang vor einer Regel ohne Klassenangabe

Dank dieser Hierarchie werden Basislabels auf der Ebene der Wurzel des Dateisystems gesetzt und dann beim tieferen Abstieg im Verzeichnisbaum weiter verfeinert und überschrieben

Lokale Regeln in file_contexts.local

Für lokale SELinux-Regeln gilt eine andere Prioritätslogik als für Basis- und modulare Policy-Definitionen

Lokale Regeln haben Vorrang vor der Policy. Jeder Eintrag aus file_contexts.local, der zum Beispiel über semanage fcontext hinzugefügt wurde, wird vor den entsprechenden Definitionen aus der Basis-Policy oder aus Modulen berücksichtigt
Die Priorisierung erfolgt von neuen zu alten Einträgen. Lokale Regeln werden nicht nach dem Prinzip „am spezifischsten“ verarbeitet, sondern in umgekehrter Reihenfolge ihrer Hinzufügung: vom zuletzt hinzugefügten Eintrag bis zum frühesten
Es wird die erste Übereinstimmung verwendet. Sobald eine passende lokale Regel gefunden wurde, wird die weitere Suche beendet
- Das bedeutet, dass ein allgemeinerer, aber später hinzugefügter Ausdruck einen genaueren, aber früher erstellten Ausdruck überdecken kann

Daher erfordern lokale Regeln besondere Sorgfalt: Ein zu weit gefasster Ausdruck, der über semanage fcontext hinzugefügt wurde, kann unerwartet genauere Basisdefinitionen der Policy überdecken

Genau aus diesem Grund sollten lokale reguläre Ausdrücke möglichst eng gefasst und zielgerichtet sein, sodass sie nur den tatsächlich benötigten Abschnitt des Verzeichnisbaums überschreiben

Befehl matchpathcon

matchpathcon fragt die System-Policy ab und gibt den Standardkontext aus, der mit dem angegebenen Pfad verknüpft ist

Das Werkzeug ist speziell für die Analyse des erwarteten Kontexts nützlich und nicht für den aktuellen Inhalt von xattr
Dieses Dienstprogramm verwaltet keine Regeln, sondern zeigt lediglich das Ergebnis der Pfadprüfung gegen die File-Context-Datenbank an

Hauptziele bei der Verwendung von matchpathcon

verstehen, welches Label ein Pfad haben sollte
das tatsächliche Label mit der Policy-Erwartung vergleichen
im Voraus prüfen, welchen Kontext ein neuer Pfad nach dem Ausführen von restorecon erhält

Prüfschichten

Prüfschichten entsprechend der Priorität der Regeln (von der niedrigsten zur höchsten Priorität)

Basisregeln der Policy (file_contexts)
Regeln für Home-Verzeichnisse (file_contexts.homedirs)
Systemweite Pfad-Aliase der Distribution (file_contexts.subs_dist)
Lokale Äquivalenzregeln (file_contexts.subs)
lokale administrative Änderungen (file_contexts.local)

Optionen

Zunächst verwenden wir den Befehl ohne Parameter, um das erwartete Label für die Datei /etc/resolv.conf anzusehen

Anschließend vergleichen wir es mit dem tatsächlichen Label mittels ls

matchpathcon /etc/resolv.conf
ls -Z /etc/resolv.conf

Für die Problemdiagnose — insbesondere um zu prüfen, ob der auf dem Datenträger vorhandene Kontext mit dem Standardkontext aus der Policy übereinstimmt — ist auch der Parameter -V (Verify) praktisch
Zur Veranschaulichung erzeugen wir eine Situation, in der das aktuelle Label nicht mit dem erwarteten übereinstimmt

cp -a /etc/hosts /var/log/hosts

matchpathcon -V /var/log/hosts
/var/log/hosts has context system_u:object_r:net_conf_t:s0, should be system_u:object_r:var_log_t:s0

Wichtig ist zu beachten, dass das Dienstprogramm matchpathcon für manche Pfade <<none>> zurückgeben kann (zum Beispiel für Dateien in tmp)

Das ist ein spezieller interner Wert in der Datenbank file_contexts: Er bedeutet, dass für diesen Pfad und Objekttyp kein erwarteter Standardkontext gefunden wurde oder dass dieser Pfad kein Label über File Context erhalten soll

Der Objekttyp kann mit dem Parameter -m (mode) erzwungen angegeben werden
Das ist besonders wichtig für Pfade, die noch nicht existieren, oder wenn ein konkretes Szenario geprüft werden soll: „Was wäre, wenn dies ein Verzeichnis wäre?“ oder „Was wäre, wenn dies eine Datei wäre?“

matchpathcon -m dir /etc/dir
matchpathcon -m file /var/log/mylog.log

Zuordnung der Objekttypen in file_contexts und der ausgeschriebenen Werte für den Parameter -m

matchpathcon -m	file_contexts
file
dir
lnk_file
sock_file
pipe
chr_file
blk_file

Am häufigsten werden die Typen file, dir, lnk_file verwendet

Für Skripte und Automatisierung ist der Parameter -n (no path) praktisch

matchpathcon -n /etc/hosts

Die Ausgabe enthält dann nicht den Pfad, sondern nur das Ergebnis der Prüfung des erwarteten File Context

Schließlich kann statt der aktuellen auch eine alternative Datei file_contexts verwendet werden
Das kann für Testzwecke nützlich sein; dafür dient der Parameter -f (file contexts)

matchpathcon -f /tmp/test_file_contexts /srv/myapp

Außerdem kann mit dem Parameter -P (Policy) ein alternativer Pfad für einen vollständigen Policy-Satz verwendet werden

Spezielle File Contexts für Dateisysteme und Mount-Optionen

In den vorherigen Schritten wurde das klassische SELinux-Modell betrachtet

Ein Pfad wird mit einer Regel aus file_contexts abgeglichen
Danach erhält die Datei den erwarteten Kontext über restorecon, setfiles oder bei der Erstellung eines neuen Objekts

Dieses Modell arbeitet auf der Ebene einzelner Inodes und Pfade

Beim normalen Einhängen eines Dateisystems wird — sofern es xattrs unterstützt — der Kontext jeder Datei aus dem security.selinux-Attribut der jeweiligen Datei übernommen

Wenn das Dateisystem keine xattrs unterstützt, erhalten die Objekte standardmäßig einen einheitlichen Kontext, der vom Typ des Dateisystems abhängt

In dieser Lektion wird der Mount-Mechanismus behandelt, mit dem die VFS (Virtual File System) des Linux-Kernels Kontexte „on the fly“ zuweisen kann, wobei pfadbasierte Labeling-Regeln ignoriert oder ergänzt werden

Mount Context

Wenn ein Dateisystem mit speziellen SELinux-Optionen eingehängt wird, ändert der Kernel die Art der Label-Verarbeitung

Das System greift auf eine Datei zu
Der Kernel erkennt, dass für den Mount-Punkt eine feste Regel definiert ist
Das tatsächliche Label auf dem Datenträger wird ignoriert (oder gar nicht erst abgefragt)
SELinux verwendet den Kontext, der im Arbeitsspeicher durch die Parameter des Befehls mount festgelegt wurde

Wichtig ist zu verstehen, dass Mount-Optionen weder die Dateiattribute auf dem Datenträger noch die File-Context-Regeln physisch verändern

Stattdessen erzeugen sie eine temporäre virtuelle Projektion der Labels im Arbeitsspeicher

Diese Ersetzung gilt genau so lange, wie das Dateisystem eingehängt ist

Sobald die Ressource ausgehängt wird (mit dem Befehl umount), verschwinden diese Overrides: Die lokale Datenbank file_contexts bleibt unverändert, und auf dem Datenträger bleiben exakt dieselben xattr-Attribute erhalten wie vor dem Mounten

Mount-Optionen

context (Globale Überschreibung)

Die Option context= ist in zwei Hauptfällen nützlich

das Dateisystem unterstützt keine xattr, sodass ein normales SELinux-Labeling darauf nicht möglich ist;
dem Dateisystem kann im Hinblick auf bereits vorhandene Attribute nicht vertraut werden, und beim Mounten muss vorübergehend ein einheitlicher sicherer Kontext erzwungen werden
- Ein praktisches Beispiel sind Wechselmedien (USB-Sticks)

Wenn context= gesetzt ist, versucht SELinux nicht mehr, xattr vom Datenträger zu lesen

Auch die Datenbank file_contexts wird für diesen Pfad ignoriert
Es ist dann nicht möglich, das Label einer einzelnen Datei innerhalb einer solchen Ressource mit chcon oder restorecon zu ändern — der Kernel gibt in diesem Fall einen Fehler zurück

Befehlsbeispiele

Für Wechselmedien

mount -o context="system_u:object_r:removable_t:s0" /dev/sdb1 /mnt/usb

Für eine Netzwerkressource, die vom Webserver gelesen werden soll

mount server:/export /srv/www -o context="system_u:object_r:httpd_sys_content_t:s0"

defcontext= (Standardkontext)

Die Option defcontext= dient einer anderen Aufgabe: Sie ändert den Kontext für unlabeled Dateien

Sie wirkt nur dort, wo ein Objekt kein eigenes SELinux-Label auf dem Datenträger hat

Wenn eine Datei bereits ein Label hat, verwendet SELinux dieses
Wenn kein Label vorhanden ist (zum Beispiel wenn eine Datei gerade aus einem alten System ohne SELinux-Unterstützung kopiert wurde), wird ihr „on the fly“ der in defcontext= angegebene Kontext zugewiesen

Befehlsbeispiel

mount /dev/sdb2 /test -o defcontext="system_u:object_r:samba_share_t:s0"

rootcontext= (Kontext des Mount-Punkts)

Die Option rootcontext= erlaubt es, den Kontext des Root-Inodes eines Dateisystems explizit festzulegen, bevor es im Userspace sichtbar wird

Sie bestimmt den Kontext ausschließlich für das Wurzelverzeichnis des eingehängten Dateisystems, ohne dessen Inhalt zu beeinflussen

Das ist nützlich, wenn das korrekte Label für das Verzeichnis selbst (zum Beispiel /mnt/backup) gesetzt werden soll, damit Dienste es betreten können, während die individuellen Labels aller enthaltenen Dateien auf dem Datenträger erhalten bleiben

mount -t tmpfs none /srv/chroot -o rootcontext="system_u:object_r:tmp_t:s0"

fscontext= (Kontext des Superblocks)

Weist der abstrakten Dateisysteminstanz selbst einen Kontext als Objekt zu, nicht den darin enthaltenen Dateien

Dies ist eine Low-Level-Option

Sie wird von SELinux selbst verwendet, um zu bestimmen, ob ein bestimmter Prozess (zum Beispiel ein Mount-Daemon) das Recht hat, Dateisysteme dieses Typs einzuhängen
In der täglichen Administration wird sie manuell nur äußerst selten verwendet

Aufgabe

Wir erstellen zwei Mount-Punkte

sudo mkdir -p /mnt/lab_context
sudo mkdir -p /mnt/lab_rootcontext

Wir mounten tmpfs mit einem einheitlichen Kontext

sudo mount -t tmpfs none /mnt/lab_context -o context="system_u:object_r:httpd_sys_content_t:s0"
ls -Zd /mnt/lab_context

Nun erstellen wir einige Objekte darin

touch /mnt/lab_context/file1
mkdir /mnt/lab_context/dir1
ls -lZ1 /mnt/lab_context

Jetzt versuchen wir, den Kontext manuell zu ändern

chcon -t tmp_t /mnt/lab_context/file1

Der Kernel gibt einen Fehler zurück, da bei Verwendung des Mount-Parameters context= eine Kontextänderung nicht möglich ist.

Nun versuchen wir, ein anderes Dateisystem mit dem Parameter defcontext= einzuhängen

mount -t tmpfs none /mnt/lab_rootcontext -o rootcontext="system_u:object_r:samba_share_t:s0"
ls -Zd /mnt/lab_rootcontext

Wir erstellen Objekte

touch /mnt/lab_rootcontext/file1
mkdir /mnt/lab_rootcontext/dir1
touch /mnt/lab_rootcontext/file2
ls -lZ1 /mnt/lab_rootcontext

Wie man sehen kann, wurde der Kontext der Dateien vom root-Verzeichnis geerbt

Nun versuchen wir, den Kontext zu ändern

chcon -R -t tmp_t /mnt/lab_rootcontext/*
ls -lZ1 /mnt/lab_rootcontext/

Und der Vorgang wird erfolgreich ausgeführt, da rootcontext nur den Kontext des Wurzelverzeichnisses des eingehängten Dateisystems ändert.

Das kann nützlich sein, wenn ein temporärer Speicher auf tmpfs benötigt wird, dessen Wurzel jedoch sofort den richtigen Typ haben soll, damit neue Dateien den gewünschten Kontext erben

Gleichzeitig bleibt die Möglichkeit erhalten, andere Dateien mit bereits vorhandenem, vom Wurzelverzeichnis abweichendem Kontext zu schreiben

Verwaltung von Kontexten mit semanage

Nun ist es endlich an der Zeit, die Verwaltung der File-Context-Datenbank zu betrachten

Wie bereits zuvor besprochen, überschreibt chcon direkt die erweiterten Attribute (xattr) auf dem Datenträger, teilt der SELinux-Policy-Datenbank (file_contexts) jedoch absolut nichts darüber mit

Änderungen, die mit chcon vorgenommen werden, sind im Maßstab des Systemlebenszyklus nur temporär

Sie werden bei jedem der folgenden Ereignisse unwiderruflich zerstört (durch Referenzwerte aus der Datenbank überschrieben)

der Administrator startet das Dienstprogramm restorecon manuell für dieses Verzeichnis;
es erfolgt ein Systemupdate eines Pakets (zum Beispiel des Webservers), dessen Installer eine Prüfung der Kontexte auslöst;
beim Booten wird ein vollständiges Relabeling des Dateisystems initiiert (durch Erzeugen der Datei /.autorelabel)

semanage fcontext

Damit ein Kontext alle Updates und Relabeling-Vorgänge übersteht, muss man dem SELinux-System selbst beibringen, dass ein nicht standardmäßiger Pfad nun ein bestimmtes Label haben soll

Dafür wird das Werkzeug semanage (SELinux Policy Management Tool) verwendet

Es ist das allgemeine Werkzeug zur lokalen Verwaltung von Elementen der SELinux-Policy, darunter: login mappings, SELinux users, ports, interfaces, modules, booleans, permissive types und file contexts
Für den aktuellen Schritt ist insbesondere der Bereich fcontext relevant

Verwendung

Zur Demonstration versuchen wir, ein nicht standardmäßiges Verzeichnis mit hochsensiblen Daten zu schützen

Stellen wir uns folgende Situation vor: Entwickler haben ein internes Authentifizierungssystem ausgerollt, das Sicherungskopien der Passwort-Hashes von Benutzern in einem nicht standardmäßigen Verzeichnis speichert — /opt/app_auth/vault/

mkdir -p /opt/app_auth/vault
ls -Zd /opt/app_auth/vault/

Wenn wir uns an die Analyse der Datei file_contexts aus den vorherigen Schritten erinnern, erhalten das Verzeichnis /opt/ und sein gesamter Inhalt standardmäßig den Kontext usr_t

Das ist ein öffentlicher Kontext

Die meisten laufenden Dienste und Benutzer dürfen Dateien mit diesem Label lesen.
Passwörter dort zu speichern ist unzulässig.
Daher muss für dieses Verzeichnis eine grundlegende Regel erstellt werden

Verwenden wir dazu die Parameter -a (add) und -t (Feld type)

semanage fcontext -a -t shadow_t "/opt/app_auth/vault(/.*)?"

"/opt/app_auth/vault(/.*)?" — ein regulärer Ausdruck, der das Verzeichnis selbst und absolut alle darin enthaltenen Dateien umfasst

Nun prüfen wir den Kontext des Verzeichnisses

ls -Zd /opt/app_auth/vault/

...und sehen, dass sich nichts geändert hat

Das liegt daran, dass wir zwar einen Eintrag in die Datenbank hinzugefügt haben, das bloße Hinzufügen eines Eintrags jedoch kein Relabeling auslöst
Um die Änderungen anzuwenden, wird das uns bereits bekannte Werkzeug restorecon verwendet

restorecon -Rv /opt/app_auth/vault/
ls -Zd /opt/app_auth/vault/

Ergebnis

# ls -Zd /opt/app_auth/vault/
unconfined_u:object_r:shadow_t:s0 /opt/app_auth/vault/

Prüfen wir, ob der Eintrag in der File-Context-Datenbank vorhanden ist

cat /etc/selinux/default/contexts/files/file_contexts.local

# This file is auto-generated by libsemanage
# Do not edit directly

/opt/app_auth/vault(/.*)?    system_u:object_r:shadow_t:s0

Jetzt sind die vertraulichen Daten zuverlässig geschützt!

Optionen

Das Werkzeug semanage verfügt über verschiedene nützliche Optionen; konzentrieren wir uns auf die wichtigsten

Welche nicht standardmäßigen Regeln manuell hinzugefügt wurden, kann mit der Option -l (list) zusammen mit dem Modifikator -C (Custom) angezeigt werden

semanage fcontext -lC

Den Kontexttyp für den bereits in der lokalen Datenbank registrierten Pfad /srv/myweb(/.*)? kann man mit der Option -m (modify) aktualisieren

semanage fcontext -m -t httpd_sys_rw_content_t "/srv/myweb(/.*)?"

Wichtig ist, dass der reguläre Ausdruck genau mit dem Eintrag in der Datenbank übereinstimmt, dessen Kontext wir ändern wollen

Wenn ein Dienst außer Betrieb genommen wurde und das nicht standardmäßige Verzeichnis nicht mehr benötigt wird, kann die Regel mit der Option -d gelöscht werden

semanage fcontext -d "/opt/app_auth/vault(/.*)?"

Äquivalente Pfade (Equivalence Rules)

Bei der Arbeit mit mehreren Verzeichnissen entsteht häufig die Situation, dass

bereits eine korrekt gekennzeichnete Struktur existiert
eine Kopie dieser Struktur an einem anderen Ort erstellt werden muss

Beispielaufgabe

Es gibt den Standardpfad des Webservers /var/www, wir haben jedoch beschlossen, die Dateien unserer neuen Website in einem nicht standardmäßigen Verzeichnis abzulegen, zum Beispiel auf einer separaten Festplatte, die unter /srv/myweb eingehängt ist

Wir erstellen zur Veranschaulichung mehrere Ordner im ursprünglichen Verzeichnis /var/www und bereiten das neue Verzeichnis /srv/myweb vor

mkdir -p /var/www/sessions && mkdir -p /var/www/cgi-binrestorecon -v -R /var/wwwls -Z1 /var/wwwmkdir -p /srv/mywebcp -r /var/www/* /srv/myweb/ls -Z1 /srv/myweb

Standardmäßig sind für das Verzeichnis /var/www und alle seine Unterverzeichnisse (html, cgi-bin usw.) im System bereits Dutzende komplexer regulärer Ausdrücke definiert, die die korrekten Kontexte zuweisen (zum Beispiel httpd_cache_t für /var/www/uploads(/.*)?)

Alle regulären Ausdrücke aus /var/www manuell für das neue Verzeichnis /srv/myweb umzuschreiben, wäre aufwendig, unhandlich und fehleranfällig

Für die Lösung solcher Aufgaben werden Äquivalenzregeln verwendet (Parameter -e des Befehls semanage fcontext)

semanage fcontext -a -e /var/www /srv/myweb

Änderungen anwenden

restorecon -v -R /srv/myweb

Sehen wir uns an, wie das in der Datenbank aussieht

# semanage fcontext -lCSELinux fcontext                                   type               Context/opt/app_auth/vault(/.*)?                          all files          system_u:object_r:shadow_t:s0SELinux Local fcontext Equivalence/srv/myweb = /var/www

Eine Äquivalenzregel funktioniert wie ein transparenter Alias: Wenn SELinux irgendeine Datei innerhalb von /srv/myweb/ prüft, ersetzt es in deren Pfad virtuell /srv/myweb durch /var/www und sucht erst danach Übereinstimmungen in seiner umfangreichen Datenbank regulärer Ausdrücke

Wenn es erforderlich ist, die Äquivalenzregel zu entfernen, geschieht dies mit dem bereits bekannten Parameter -d; man muss ihn lediglich anstelle des Parameters -a aus dem ursprünglichen Befehl verwenden

semanage fcontext -d -e /var/www /srv/mywebsemanage fcontext -lC

Export und Import lokaler Policies

Das Dienstprogramm semanage kann Policies mit den Befehlen semanage export und semanage import in eine Datei exportieren beziehungsweise aus einer Datei importieren

In der Praxis wird das zum Beispiel verwendet, wenn ein Administrator plant, Policies von einem Testserver auf die Produktionsumgebung zu übertragen

Export

Verwendungsbeispiel

semanage export -f /tmp/selinux_local_rules.txt

Prüfen wir, was sich darin befindet

cat /tmp/selinux_local_rules.txt
boolean -Dlogin -Dinterface -D...fcontext -a -f a -t shadow_t -r 's0' '/opt/app_auth/vault(/.*)?'module -d acpimodule -d aisexecmodule -d amtu..

Wie man sehen kann, ist die Datei logisch in drei Teile gegliedert

Bereinigungsblock (Einträge mit dem Schlüssel -D) – beim Import der Datei auf einem neuen Server (über semanage import) soll das Policy-System zu einer exakten Kopie des Quellservers werden
Daher müssen alle lokalen Einstellungen gelöscht werden
Der Schlüssel -D wird als Delete interpretiert
Lokale Regeln (im Beispiel die einzige Regel fcontext)
Block deaktivierter Policy-Module (Einträge mit dem Schlüssel -d) – das Policy-Set default policy in Debian ist gehärtet (hardened) und deaktiviert ungenutzte Module
In RHEL macht die Policy targeted genau das Gegenteil: Dort sind standardmäßig von Anfang an alle Module aktiviert, unabhängig davon, ob die entsprechende Software installiert ist oder nicht

Import

Für den Import wird der Befehl semanage import verwendet; seine Syntax sieht identisch zum Export aus

semanage import -f /tmp/selinux_local_rules.txt

Wenn uns die importierten Policies zusagen und alles Erforderliche mit matchpathcon -V geprüft wurde, wenden wir die Änderungen an

restorecon -Rv /

Wiederherstellung korrekter Labels

Relabeling mit restorecon

Der Arbeitsablauf von restorecon lässt sich vereinfacht wie folgt beschreiben

Das Werkzeug übernimmt einen Zielpfad und liest die aktive SELinux-Policy bzw. die zugehörige File-Context-Datenbasis
Der Zielpfad wird gegen die regulären Ausdrücke aus der Policy-Datenbasis abgeglichen
Das Werkzeug liest den tatsächlich gesetzten erweiterten Dateiattributwert (xattr) des Objekts direkt aus dem Dateisystem
Anschließend erfolgt ein Vergleich zwischen dem laut Policy erwarteten Kontext und dem tatsächlich gesetzten Label (Attribut) des Objekts
Falls die Prüfung rekursiv für ein Verzeichnis ausgeführt wurde, berechnet restorecon einen Hash über die dabei verwendeten regulären Ausdrücke und speichert ihn im versteckten Attribut des Verzeichnisses security.sehash
- Beim nächsten Lauf beginnt Schritt 2 dann mit dem Vergleich dieses Hashes, um Zeit zu sparen

Verwendung

In der Praxis werden drei Betriebsarten verwendet

Passive Prüfung ohne Änderungen

restorecon -nv /var/www/html/index.html

Die Option -n verhindert das Schreiben neuer Labels und versetzt das Werkzeug in den Prüfmodus

Der Parameter -v zeigt Objekte an, deren Labels vom erwarteten Zustand abweichen

Korrektur eines einzelnen Objekts

restorecon -v /var/www/html/index.html

Korrigiert den Kontext der angegebenen Datei

Praktisch werden dabei genau die Änderungen angewendet, die im vorherigen Beispiel lediglich angezeigt wurden

Massenhafte rekursive Korrektur eines Verzeichnisbaums

restorecon -Rv /var

Die Optionen -R und -r aktivieren den rekursiven Verzeichnisdurchlauf

Genau dieser Modus wird typischerweise nach dem Hinzufügen neuer Regeln mit semanage fcontext oder nach einer beschädigten Teil-Relabeling-Situation verwendet

customizable types

In SELinux existiert ein Ausnahme-Mechanismus für Relabeling mit der Bezeichnung customizable types

Dabei handelt es sich um eine vordefinierte Liste von Kontexten (Typen), die vom System als manuell administrierbar betrachtet werden

Entsprechend werden solche Dateien bei der Prüfung und beim Relabeling durch SELinux-Werkzeuge und -Mechanismen (einschließlich restorecon, .autorelabel, setfiles, fixfiles) ignoriert

Die Liste der customizable types wird aus folgender Datei gelesen

/etc/selinux/{SELINUXPOLICY}/contexts/customizable_types

Obwohl der Mechanismus der customizable types in modernen Distributionen weiterhin existiert und funktioniert, gilt er in der Administratoren-Community heute als veraltender Ansatz

Der Grund ist, dass die Datei lediglich Informationen darüber enthält, welche Typen ignoriert werden, nicht jedoch, welchen konkreten Dateien diese Typen zugewiesen wurden
In einer Störungssituation kann diese Information unwiederbringlich verloren gehen
Die File-Context-Datenbank enthält dagegen alle erforderlichen Informationen, um den gewünschten Label-Zustand im Dateisystem reproduzierbar wiederherzustellen

Um Dateien mit customizable types dennoch zwangsweise auf den vollständig erwarteten Kontext zurückzusetzen, muss restorecon mit dem Parameter -F (Force) ausgeführt werden

In diesem Fall werden alle Felder des Kontexts wiederhergestellt

restorecon -F -v /srv/custom_app

Beschleunigung durch Digest-Prüfung

Das Werkzeug restorecon_xattr

Beim rekursiven Relabeling mit restorecon -D durchläuft das Werkzeug den Verzeichnisbaum nicht nur und korrigiert Kontexte, sondern schreibt zusätzlich einen internen Digest in das xattr des Verzeichnisses.

Digest wird im erweiterten Attribut security.sehash gespeichert

Die Aufgabe dieses Digests besteht darin festzuhalten, dass dieses Verzeichnis bereits gegen einen bestimmten Satz von file_contexts-Dateien geprüft wurde, die für die Zuordnung von Pfaden zu erwarteten Kontexten verwendet werden

Beim nächsten Lauf von restorecon -D wird dieser Hash zur Prüfung herangezogen und bei Bedarf aktualisiert, falls er veraltet ist

In modernen RHEL-Versionen wird zur Berechnung dieses Werts der kryptographische Algorithmus SHA-256 verwendet (in älteren Systemen kam SHA-1 zum Einsatz). Red Hat/Fedora verwenden seit RHEL 9 bzw. Fedora 34+ beim Paket-Build einen eigenen Patch für den Quellcode

In den Paketquellen findet sich dazu direkt eine Datei mit dem Namen 0001-Use-SHA-2-instead-of-SHA-1.patch

Debian verwendet weiterhin SHA-1

Das ist in diesem Kontext jedoch unkritisch, da der Hash im Verzeichnis-xattr nicht für Sicherheitsfunktionen oder Verschlüsselung verwendet wird

restorecon_xattr

Für die Arbeit mit diesen internen Digest-Einträgen (Anzeigen/Bereinigen) stehen folgende Kommandos zur Verfügung

restorecon -D (Hashes erzeugen / Dateien unter Verwendung vorhandener Hashes prüfen)
restorecon -I (Hashes erzeugen / neu erzeugen, wobei vorhandene ignoriert werden)
sowie das separate Werkzeug restorecon_xattr (Hashes anzeigen / löschen)

Funktionen von restorecon_xattr

Verzeichnisse anzeigen, in denen security.sehash vorhanden ist
Digest und dessen Status im Vergleich zum aktuellen Policy-Satz anzeigen
nur veraltete Digest-Einträge löschen
alle Digest-Einträge in einem angegebenen Verzeichnisbaum löschen

Praxisbeispiel mit einigen Hashes

Start von restorecon mit dem Flag -D und rekursivem Modus -R

restorecon -RDv /var/log

Anzeige des Ergebnisses mit restorecon_xattr (zusätzlich mit -r für rekursive Ausgabe)

restorecon_xattr -r /var/log

Zum Entfernen von Hashes, die nicht mehr zum aktuellen Policy-Satz passen, wird der Parameter -d verwendet

Das Werkzeug berechnet einen neuen Hash und entfernt den alten Hash bei Nichtübereinstimmung (neue Hashes werden dabei nicht geschrieben)

restorecon_xattr -d -r /var/www

Vollständiges Entfernen aller Digests

restorecon_xattr -D -r /var/www

Dabei werden alle security.sehash-Einträge aus dem Verzeichnisbaum entfernt, unabhängig davon, ob sie noch aktuell sind oder nicht

Der nächste Lauf von restorecon -D muss die Digests anschließend vollständig neu erzeugen

Wichtig ist, dass sich der Nutzen von restorecon -D erst bei rekursiver Verarbeitung (-R / -r) entfaltet

Nach einem erfolgreichen rekursiven Relabeling wird beim erneuten Ausführen von restorecon -D (mit denselben Parametern und demselben Policy-Satz) der gespeicherte Digest zur Beschleunigung des Verzeichnisdurchlaufs verwendet
Das ist insbesondere bei der Prüfung großer Verzeichnisbäume oder sogar des gesamten Dateisystems ab / nützlich

Das bedeutet: Wenn der Parameter -D gesetzt ist, wird für Verzeichnisse ohne vorhandenen Hash ein neuer Digest berechnet und in den Attributen gespeichert

Falls für ein Verzeichnis bereits ein Hash existiert, prüft restorecon dessen Gültigkeit, indem es ihn mit dem neu aus der File-Context-Datenbank berechneten Wert vergleicht. Bei Übereinstimmung wird das Verzeichnis beschleunigt verarbeitet. Bei Nichtübereinstimmung erfolgt die Prüfung des aktuellen Verzeichnisses und aller Unterverzeichnisse im normalen Modus, also so, als wäre -D nicht gesetzt

Wird der Parameter -D nicht verwendet, nutzt restorecon den Mechanismus security.sehash bei der Prüfung überhaupt nicht

Wird restorecon -I verwendet, wird ein bereits gespeicherter Digest ignoriert

Selbst wenn security.sehash formal übereinstimmt, vertraut restorecon diesem Eintrag nicht und führt im rekursiven Modus zwangsweise eine erneute vollständige Label-Prüfung durch; anschließend wird der Digest aktualisiert
Voraussetzung ist, dass das Flag -n nicht gesetzt ist und während der Ausführung keine Fehler auftreten

Anwendungsbeispiel

restorecon -RIv /var/log

Das Verzeichnis wird rekursiv geprüft, und jeder Hash wird unabhängig davon, ob bereits ein Digest in den Attributen vorhanden ist, neu erzeugt

Relabeling-Werkzeuge

Die Werkzeuge für Relabeling lassen sich in drei Ebenen unterteilen

setfiles
- Das grundlegende, low-level ausführbare Binärprogramm (in C geschrieben)
- Es bildet den Kernmechanismus zur Anwendung der Policy
- restorecon arbeitet auf Basis von setfiles
restorecon
- Ein Werkzeug auf Benutzerebene, das für gezielte administrative Eingriffe vorgesehen ist
- restorecon findet, lädt und verwendet automatisch die aktuell aktive SELinux-Policy
- Das Werkzeug restorecon wird durch dieselbe ausführbare Datei implementiert wie setfiles
- Der Betriebsmodus wird über argv[0] gewählt, also über den Namen, unter dem das Programm aufgerufen wird
fixfiles
- Dabei handelt es sich nicht um eine Binärdatei, sondern um ein Shell-Skript, das den Aufruf von setfiles und restorecon für globale Systemaufgaben automatisiert
- Es ist eine skriptbasierte Wrapper-Schicht für typische Wartungsoperationen wie check, verify, restore, relabel, onboot sowie für paketbezogene und inkrementelle Betriebsarten
- Das Werkzeug kann mit der Datenbank des Paketmanagers (RPM) arbeiten
- So kann es beispielsweise alle Dateien ermitteln, die zu einem bestimmten Paket gehören, und ausschließlich diese neu labeln
- Außerdem steuert es den Ablauf eines vollständigen System-Relabelings beim Booten

Betriebsarten von fixfiles

fixfiles check / fixfiles verify

check und verify sind Betriebsarten ohne Änderung der Labels

Sie geben alle inkorrekten Labels aus und zeigen dabei den alten sowie den neuen Kontext an, schreiben jedoch nichts zurück
Das ist ein praktischer administrativer Audit-Modus vor einem Relabeling oder nach Änderungen an den Regeln

Beispiel

chcon -R -t tmp_t /var/wwwchcon -R -t shadow_t /srvfixfiles check /var/www /srv

fixfiles restore

restore stellt inkorrekte Labels wieder her

Beispiel

fixfiles restore /var/www /srv/app

fixfiles relabel

relabel ist für ein vollständiges Relabeling des gesamten Dateisystems vorgesehen

Das Werkzeug schlägt vor, den Inhalt von /tmp zu löschen
Anschließend werden alle inkorrekten Dateilabels so korrigiert, dass sie den installierten file_contexts entsprechen

Beispiel

fixfiles relabel

fixfiles onboot

onboot führt das Relabeling nicht sofort aus, sondern bereitet das System so vor, dass das Relabeling beim nächsten Systemstart erfolgt

fixfiles onboot

Optionen

Wichtige Optionen

Unix	Beschreibung
-F	(Force) Setzt den Kontext auch bei Dateien mit customizable types zwangsweise zurück
-f	(force clear) Leert die temporären Verzeichnisse /tmp und /var/tmp automatisch vor Beginn der Ausführung, ohne interaktive Rückfragen Das ist besonders nützlich für Automatisierungsskripte
-C PREVIOUS_FILECONTEXT	(Compare) Vergleicht einen alten file_contexts-Stand mit dem aktuellen und stellt Kontexte nur dort wieder her, wo dies erforderlich ist
-N "YYYY-MM-DD HH:MM"	(Newer) Beschränkt die Verarbeitung auf Dateien, die nach dem angegebenen Zeitpunkt erstellt wurden
-B	Im Modus restore werden nur Dateien berücksichtigt, die heute verändert wurden Im Modus onboot schreibt derselbe Schalter das aktuelle Datum in /.autorelabel, wodurch das Relabeling beschleunigt werden kann
-M	(Mounts) Führt vor dem Relabeling Bind-Mounts für Dateisysteme aus, sodass auch Kontexte von Objekten korrekt repariert werden können, über denen etwas eingehängt ist
-T nthreads	(Threads) Konfiguriert die parallele Verarbeitung mit mehreren Threads oder deaktiviert diese bei -T 1
-l LOGPATH	(Log) Leitet die gesamte Ausgabe, also sowohl Standardausgabe als auch Fehlermeldungen, in die angegebene Logdatei statt auf den Bildschirm um