Linux/SELinux/04/07 Kontexte: Unterschied zwischen den Versionen

Aktuelle Version vom 16. Juni 2026, 09:25 Uhr

Linux/SELinux/04/07 Kontexte - Struktur und Auslesen des Sicherheitskontexts

Kontext und Label

Im SELinux-System (Security-Enhanced Linux) wird der Zugriff auf Ressourcen nicht auf Grundlage der Eigentümerrechte gesteuert (wie im klassischen DAC-Modell), sondern auf Grundlage von Sicherheitskontexten

Wichtig

SELinux-Richtlinienregeln (MAC) werden erst nach den klassischen Linux-Zugriffsrechten (DAC — Eigentümer, Gruppe, rwx) überprüft.
Wenn bereits die DAC-Regeln den Zugriff verweigern, blockiert das System sofort. SELinux wird in diesem Fall gar nicht erst angewendet und erzeugt folglich auch keine AVC-Meldungen im Audit-Log.

Ein Kontext ist ein spezielles Label, das jedem Systemobjekt zugewiesen wird (Dateien, Prozessen, Netzwerkports)

Datei-Labels werden direkt im Dateisystem als erweiterte Dateiattribute (Extended Attributes oder xattr) gespeichert

SELinux verwendet dabei das Attribut mit dem Namen security.selinux

Auf das Vorhandensein erweiterter Attribute weist ein Punkt am Ende der Attributanzeige bei Verwendung von ls -l hin

sudo ls -l /var/log/apt/
total 388
-rw-r--r--. 1 root root 43628 Mar 21 12:52 eipp.log.xz
-rw-r--r--. 1 root root 54225 Mar 21 12:52 history.log
-rw-r-. 1 root adm 283440 Mar 21 12:52 term.log

Kontextzeichenfolge

Anatomie der Kontextzeichenfolge

Das vollständige Label eines Sicherheitskontexts besteht aus vier (manchmal fünf) durch Doppelpunkte getrennten Elementen

Typische Struktur

user : role : type : level

Typen

Bedeutung des Typs (Type) in der Targeted Policy

In den meisten modernen Distributionen (RHEL, CentOS, Fedora, Debian) wird standardmäßig die Policy Targeted verwendet

In diesem Modell liegt der Schwerpunkt auf Type Enforcement (TE) — der erzwungenen Zuweisung von Typen

Zur Analyse von Sicherheitslabels (Kontexten) werden Standard-Linux-Werkzeuge mit der zusätzlichen Option -Z verwendet.

Die Option -Z wird von fast allen grundlegenden Befehlen unterstützt

cp -Z — kopiert eine Datei und weist ihr sofort den korrekten Kontext des Zielverzeichnisses zu (den Standardkontext des Verzeichnisses)

Im Gegensatz dazu bewahrt der Parameter -a den ursprünglichen Kontext der Datei

mkdir -Z — erstellt ein Verzeichnis, das sofort den Standardkontext erhält (ohne dass restorecon ausgeführt werden muss)
Außerdem die Anzeigeprogramme: ls -Z (Dateien), ps -Z (Prozesse), id -Z (Benutzer)

Kontext von Dateien und Verzeichnissen

Vererbung (Inheritance): Standardmäßig erben neu erstellte Dateien und Verzeichnisse den SELinux-Typ ihrer übergeordneten Verzeichnisse. Wenn Sie beispielsweise eine neue Datei im Verzeichnis /etc erstellen, das mit dem Typ etc_t gekennzeichnet ist, erhält die neue Datei automatisch denselben Typ.

Zum Anzeigen des Kontexts von Dateien wird der Befehl ls -Z verwendet

ls -Z /var/log

Ausgabe

system_u:object_r:var_log_t:s0 README
system_u:object_r:var_log_t:s0 alternatives.log
system_u:object_r:httpd_log_t:s0 apache2
system_u:object_r:apt_var_log_t:s0 apt
system_u:object_r:auditd_log_t:s0 audit
system_u:object_r:faillog_t:s0 btmp
system_u:object_r:var_log_t:s0 cloud-init-output.log
system_u:object_r:var_log_t:s0 cloud-init.log
system_u:object_r:var_log_t:s0 dpkg.log

Interpretation der Typen

Bei der Analyse von Kontexten sollte man auf die Suffixe der Typen achten, da diese häufig auf ihren Zweck hinweisen

Kontext	Beschreibung
_t	Allgemeines Suffix für Typen (type)
_exec_t	Typ, der ausführbaren Dateien (Binärdateien) zugewiesen wird
_conf_t	Typ für Konfigurationsdateien
_log_t	Typ für Logdateien
_tmp_t	Typ für temporäre Dateien

Extended Attributes

Speicherung auf dem Datenträger

SELinux-Sicherheitskontexte werden nicht in einer separaten Datenbank oder einem zentralen Journal gespeichert

Sie sind ein integraler Bestandteil des Dateisystems und werden zusammen mit den Dateien verschoben, wenn diese kopiert oder verschoben werden (sofern die verwendeten Werkzeuge die Beibehaltung der Attribute unterstützen)

Begriff Extended Attributes (xattr)

Erweiterte Attribute (xattr) sind eine Funktion von Dateisystemen (wie Ext4, XFS, Btrfs), die es ermöglichen, einer Datei oder einem Verzeichnis zusätzliche Metadaten im Format „Schlüssel=Wert“ zuzuordnen

Während Standardattribute (Zugriffsrechte, Eigentümer, Zeitstempel) eine feste Struktur haben, ermöglichen erweiterte Attribute die Speicherung beliebiger Daten

Hier speichert SELinux die Kontextzeichenfolge unter dem Schlüssel security.selinux

Namensräume

Namensräume (Namespaces)

Zur Vermeidung von Konflikten und zur Gewährleistung der Sicherheit sind erweiterte Attribute in Namensräume unterteilt

Jeder Namensraum hat eigene Zugriffsregeln

Namensraum	Zweck	Zugriff
security	Wird von Sicherheitsmodulen verwendet (SELinux, AppArmor, IMA)	Der Zugriff ist auf den Kernel und Prozesse mit besonderen Privilegien beschränkt
system	Wird vom Kernel zur Speicherung von Systemdaten verwendet, zum Beispiel von Access Control Lists (ACL)	In der Regel nur für den Kernel zugänglich
user	Ist für Benutzeranwendungen und Dokumente vorgesehen	Wird durch die standardmäßigen Zugriffsrechte (DAC) geregelt
trusted	Zur Speicherung von Daten, auf die nur Prozesse mit dem Privileg CAP_SYS_ADMIN zugreifen dürfen	Für normale Benutzer unsichtbar, selbst wenn sie Eigentümer der Datei sind

Attribute

Arbeit mit Attributen

getfattr und setfattr

Obwohl für die Verwaltung von SELinux häufiger spezialisierte Befehle (chcon, semanage) verwendet werden, ermöglichen Low-Level-Werkzeuge aus dem Paket attr, zu sehen, wie diese Daten aus Sicht des Dateisystems aussehen

Attribute anzeigen

Attribute anzeigen (getfattr)

Zum Lesen eines Attributs einer bestimmten Datei wird der Befehl getfattr verwendet

Um den SELinux-Kontext anzuzeigen, muss der vollständige Schlüsselname im Namensraum security angegeben werden

getfattr -n security.selinux /etc/passwd

Um alle vorhandenen Attribute einer Datei anzuzeigen, wird ein Befehl der Form getfattr -m . -d /etc/passwd verwendet

Attribute setzen

Attribute setzen (setfattr)

Der Befehl setfattr ermöglicht es, den Kontextwert manuell zu ändern

Diese Aktion erfordert Superuser-Rechte und wird in der Regel nur zu Debugging-Zwecken oder für ein tieferes Systemverständnis ausgeführt

touch testfile
setfattr -n security.selinux -v "unconfined_u:object_r:user_home_t:s0" testfile

Bei der Verwendung von setfattr prüft das System die Korrektheit des eingegebenen Kontexts nicht so streng, wie es die SELinux-Werkzeuge tun

Ein Fehler in der Zeichenfolge kann dazu führen, dass die Datei für Zielprozesse unzugänglich wird.

Anwendung

Modus prüfen

getenforce

Wenn der Befehl Enforcing zurückgibt, schalten Sie ihn vorübergehend mit dem Befehl setenforce 0 auf Permissive um.

Blockierende Situation

Erzeugen einer blockierenden Situation

Sie haben eine Datei erstellt, ihr jedoch versehentlich (oder absichtlich) einen Kontext zugewiesen, der weder für einen normalen Benutzer noch für das aktuelle Verzeichnis vorgesehen ist

touch /tmp/testfile

ls -Z /tmp/testfile

unconfined_u:object_r:user_tmp_t:s0 /tmp/testfile

Wie an der Konsolenausgabe zu sehen ist, hat die Datei den Typ user_tmp_t, der typisch für Dateien im Verzeichnis /tmp ist

Viele Programme haben Leserechte auf dieses Verzeichnis
Weisen wir der Datei nun den Typ shadow_t zu

Unter normalen Umständen haben nur Passwortdateien diesen Typ, und normalen Prozessen sowie Benutzern ist die Interaktion mit solchen Dateien untersagt

setfattr -n security.selinux -v "system_u:object_r:shadow_t:s0" /tmp/testfile

Zum Setzen von Attributen kann auch das Werkzeug chcon verwendet werden; in diesem Fall sieht der Befehl wie folgt aus

chcon -t shadow_t /tmp/testfile

Über das Werkzeug chcon sprechen wir etwas später noch genauer besprochen

Prüfung, ob die Attribute korrekt gesetzt wurden

sudo ls -Z /tmp/testfile

unconfined_u:object_r:shadow_t:s0 /tmp/testfile

Schließlich muss nun ein Verstoß provoziert werden; dazu versuchen wir, die Datei zu lesen oder zu ändern

echo "test" > /tmp/testfile

Nun betrachten wir die AVC-Ereignisse mit dem Werkzeug ausearch

ausearch -m AVC -ts recent

Und wir werden nichts sehen, denn standardmäßig gelangt ein Benutzer, der sich per SSH oder über die Konsole anmeldet, in den Standardrichtlinien (Targeted Policy) in die Domäne unconfined_t (uneingeschränkt)

Das kann mit dem Befehl id -Z geprüft werden

sudo id -Z

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Prozessen in der Domäne unconfined ist praktisch alles erlaubt

SELinux sieht, dass ein „uneingeschränkter“ Prozess eine Datei liest, und auch wenn die Datei einen ungewöhnlichen Typ hat (wie shadow_t), betrachtet es dies für diesen konkreten Prozess nicht als Richtlinienverstoß

Um die Funktionsweise von SELinux zu prüfen, muss das Lesen der Datei mit dem Kontext eines anderen Prozesses gestartet werden, zum Beispiel httpd_t.

Da der Typ httpd_t keinen Zugriff auf ausführbare Dateien des Typs bin_t hat (dieser Typ ist für cat gesetzt), erstellen wir eine Kopie von cat und weisen ihr den Typ httpd_t zu

cp /usr/bin/cat /tmp/fake_httpd

setfattr -n security.selinux -v "system_u:object_r:httpd_t:s0" /tmp/fake_httpd sudo oder chcon -t httpd_t /tmp/fake_httpd

Prüfung

systemd-run -p SELinuxContext=system_u:system_r:httpd_t:s0 /tmp/fake_httpd /tmp/testfile

In SELinuxContext wird der Kontext für den Start angegeben

Anschließend wird cat mit dem Sicherheitstyp httpd_t gestartet und versucht, /tmp/testfile zu lesen

Wir betrachten die AVC-Einträge

ausearch -m AVC -ts recent -c fake_httpd

type=AVC msg=audit(1774103099.579:33834): avc: denied { getattr } for pid=38589 comm="fake_httpd" path="/tmp/testfile" dev="tmpfs" ino=117 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:shadow_t:s0 tclass=file permissive=1

{ getattr } zeigt, welche konkrete Aktion das Subjekt auszuführen versucht hat
tcontext zeigt den Kontext des Objekts, auf das ein unbefugter Zugriff versucht wurde
scontext zeigt den Kontext des Subjekts, das versucht hat, auf das Objekt mit tcontext zuzugreifen
path zeigt den Pfad zur Datei

Wie im Log zu sehen ist, wurde der Zugriff für fake_httpd bereits beim Lesen der Dateiattribute verweigert!

Außerdem ist zu erkennen, dass es für SELinux keine Rolle spielt, unter welchem Benutzer der Prozess gestartet wurde, der gegen die Regeln verstoßen wollte

Auch Zugriffsrechte wie chmod 777 beeinflussen das Ergebnis nicht

Versuchen wir dasselbe mit dem Typ user_home_t

Dieser Typ wird für Dateien im Home-Verzeichnis eines Benutzers verwendet
Der Prozess httpd darf keine Leserechte auf Dateien im Home-Verzeichnis eines Benutzers haben

Zur Veranschaulichung geben wir der Datei zusätzlich Vollzugriff für alle

setfattr -n security.selinux -v "system_u:object_r:user_home_t:s0" /tmp/testfile

chmod 777 /tmp/testfile

systemd-run -p SELinuxContext=system_u:system_r:httpd_t:s0 /tmp/fake_httpd /tmp/testfile

ausearch -m AVC -ts recent -c fake_httpd

Und erneut erscheint im Log eine Meldung über einen Verstoß

type=AVC msg=audit(1774103685.752:33957): avc: denied { getattr } for pid=38729 comm="fake_httpd" path="/tmp/testfile" dev="tmpfs" ino=117 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file permissive=1

Wichtig: Wenn dieselbe verbotene Aktion mehrmals hintereinander ausgeführt wird, erscheint sie nicht jedes Mal im Log, um Spam zu vermeiden

Um den SELinux-Cache zu leeren, kann ein Neustart des Betriebsmodus verwendet werden

 setenforce 1 && setenforce 0

change context (chcon)

SELinux-Kontext einer Datei oder eines Verzeichnisses ändern

Funktionen

vollständigen Kontext auf einmal setzen
einzelne Kontextfelder (etwa den Typ) ändern
Kontext einer anderen Datei übernehmen (--reference)

Zuvor wurden setfattr und chcon verwendet

Wie man sehen kann, ist chcon komfortabler, da sich damit einzelne Felder gezielt ändern lassen
Außerdem wird chcon als primäres Werkzeug für die Arbeit mit SELinux-Kontexten empfohlen, während setfattr ein Low-Level-Werkzeug ist, das mit Nicht-SELinux-xattr arbeitet

Die wichtigste Einschränkung von chcon (genauso wie von setfattr) besteht darin, dass die Änderungen nicht dauerhaft sind

Sie können nach restorecon oder nach einem vollständigen Relabeling des Dateisystems verloren gehen

Daher wird dieses Werkzeug hauptsächlich verwendet für

Laborübungen
schnelle Diagnose
temporäre Überprüfung von Richtlinien

Die dauerhafte Konfiguration von Labels erfolgt mit dem Werkzeug semanage und einem anschließenden Aufruf von restorecon

Näheres zum Werkzeug semanage folgt in den nächsten Lektionen

Verwendung

Zur Demonstration erstellen wir die erforderlichen Dateien und Verzeichnisse und prüfen den Kontext des Verzeichnisses sowie der Dateien

mkdir -p /tmp/web_content/images

cd /tmp/web_content/

touch manual

touch test.conf

touch images/image.png

ls -Zd /tmp/web_content/

ls -Z -1 /tmp/web_content/

Diesem Verzeichnis wurde der Typ user_tmp_t vererbt, ebenso den darin enthaltenen Dateien

Versuchen wir, den vollständigen Kontext manuell zu setzen

chcon system_u:object_r:httpd_sys_content_t:s0 manual

ls -Z -1

Diese Methode wird nur selten verwendet, da für SELinux in der Regel das Feld type am wichtigsten ist

Um das Feld type zu ändern, wird der Parameter -t verwendet

chcon -t shadow_t manual

Zum Ändern der Felder user und role werden entsprechend die Optionen -u und -r verwendet

Der Parameter -R erlaubt die rekursive Verarbeitung von Verzeichnissen

Weisen wir dem gesamten Verzeichnis web_content den Typ httpd_sys_content_t zu und verwenden dabei den Parameter -v, um Details anzuzeigen

chcon -R -v -t httpd_sys_content_t /tmp/web_content

ls -Z -1

Um den Kontext von einem bereits korrekt gelabelten Objekt zu kopieren, kann die Option --reference=RFILE verwendet werden

touch /tmp/ref

chcon -R --reference=/tmp/ref /tmp/web_content

ls -Z -1

Parameter für den Umgang mit Symlinks

Unix	GNU	Beschreibung
	--dereference	(standardmäßig verwendet) wirkt nicht auf den symbolischen Link selbst, sondern auf das Objekt, auf das er verweist
-h	--no-dereference	ändert den symbolischen Link selbst und nicht das Zielobjekt

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 (Perl-compatible regular expression)
- Beispielsweise bedeutet der Ausdruck /var/www(/.*)?: sowohl das Verzeichnis /var/www selbst als auch absolut jede Datei oder jedes Unterverzeichnis darin
- Wichtig zur PCRE-Verarbeitung:
  - Das einzige verwendete Flag ist PCRE2_DOTALL. Dadurch stimmt der Platzhalter . (Punkt) mit jedem beliebigen Zeichen überein, einschließlich Zeilenumbrüchen
  - Zeichenfolgen, die Pfade darstellen, werden strikt als Bytes verarbeitet. Das bedeutet, dass Nicht-ASCII-Zeichen (wie beispielsweise deutsche Umlaute) unter Umständen nicht durch einen einzelnen Platzhalter abgeglichen werden können
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

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-bin
restorecon -v -R /var/www
ls -Z1 /var/www
mkdir -p /srv/myweb
cp -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 -lC
SELinux fcontext                  type        Context
/opt/app_auth/vault(/.*)?             all files     system_u:object_r:shadow_t:s0

SELinux 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/myweb
semanage 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 -D
login -D
interface -D
...
fcontext -a -f a -t shadow_t -r 's0' '/opt/app_auth/vault(/.*)?'
module -d acpi
module -d aisexec
module -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 /

← Zurück

Weiter →

Dirkwagner (Diskussion | Beiträge)

Aktuelle Version vom 16. Juni 2026, 09:25 Uhr

Kontext und Label

Kontextzeichenfolge

Typen

Kontext von Dateien und Verzeichnissen

Interpretation der Typen

Extended Attributes

Namensräume

Attribute

Attribute anzeigen

Attribute setzen

Anwendung

Modus prüfen

Blockierende Situation

change context (chcon)

Verwendung

Woher kommt der „richtige“ Kontext (File Contexts)

Wo SELinux Informationen über erwartete Kontexte speichert

Struktur der File-Context-Dateien

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

Format einer File-Context-Regel

pathname

file_type

context

Prioritäten der Regeln

Basis- und modulare Policy-Definitionen

Lokale Regeln in file_contexts.local

Befehl matchpathcon

Prüfschichten

Optionen

Verwaltung von Kontexten mit semanage

semanage fcontext

Verwendung

Optionen

Äquivalente Pfade (Equivalence Rules)

Beispielaufgabe

Export und Import lokaler Policies

Export

Import