Linux/SELinux/04/09 Dateisysteme

← Zurück

Weiter →

Linux/SELinux/04/09 Dateisysteme

Mount-Optionen

Standardmäßig

• wird beim Einbinden eines Dateisystems der Sicherheitskontext für jede Datei aus dem erweiterten Attribut (xattr) der Datei gelesen

Dateisysteme ohne xattr

• Wenn ein Dateisystem jedoch keine xattr unterstützt (wie FAT oder NFS) oder dem Datenträger nicht vertraut wird (z. B. USB-Sticks), kann der Sicherheitskontext direkt beim Mounten erzwungen oder angepasst werden

context=

Globale Überschreibung

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

1. Das Dateisystem unterstützt keine xattr, sodass ein normales SELinux-Labeling darauf nicht möglich ist
2. Dem Dateisystem kann im Hinblick auf bereits vorhandene Attribute nicht vertraut werden, und beim Mounten muss vorübergehend ein einheitlicher sicherer Kontext erzwungen werden (z. B. Wechselmedien)

Wirkung

• Ist context= gesetzt, versucht SELinux nicht, xattr vom Datenträger zu lesen
• Die Datenbank file_contexts wird für diesen Pfad ignoriert

Wichtig

• Es ist 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 (Operation not supported)
• Die ursprünglichen Kontexte (falls auf der Festplatte vorhanden) bleiben erhalten und sind bei einem späteren Mounten ohne context= wieder sichtbar

Beispiele

Wechselmedien

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

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

Ändert des Kontexts 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 wird der in defcontext= angegebene Kontext zugewiesen
  (zum Beispiel, wenn eine Datei aus einem alten System ohne SELinux-Unterstützung kopiert wurde)

Neue Dateien erben dieses Label und speichern es physisch ab

• sofern das Dateisystem xattr unterstützt

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

Low-Level-Option

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

Mount-Optionen prüfen

Verhalten von Mount-Optionen prüfen

Wir erstellen zwei Mount-Punkte:

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

Wir mounten tmpfs mit einem global erzwungenen Kontext (context=):

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 und versuchen, den Kontext manuell zu ändern:

touch /mnt/lab_context/file1
mkdir /mnt/lab_context/dir1
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 für einzelne Dateien blockiert wird.

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

mount -t tmpfs none /mnt/lab_rootcontext -o rootcontext="system_u:object_r:samba_share_t:s0"
touch /mnt/lab_rootcontext/file1
mkdir /mnt/lab_rootcontext/dir1
ls -lZ1 /mnt/lab_rootcontext

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

Nun versuchen wir, den Kontext manuell zu ändern:

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

Der Vorgang wird erfolgreich ausgeführt, da rootcontext= nur den Kontext des Wurzelverzeichnisses des eingehängten Dateisystems starr festlegt, die darin erstellten Dateien jedoch individuell anpassbar bleiben.

NFS und mehrfache Mounts

Besonderheiten bei NFS und mehrfachen Mounts

Standardmäßig werden NFS-Einhängungen auf der Client-Seite mit einem Standardkontext gekennzeichnet (meist nfs_t). Dienste wie der Apache-HTTP-Server oder MariaDB können oft nicht auf nfs_t zugreifen, weshalb der Kontext beim Mounten überschrieben werden muss.

• Hinweis: Alternativ zum Überschreiben des Kontexts können auch SELinux-Booleans (z. B. httpd_use_nfs) verwendet werden, um Diensten den Zugriff zu gestatten.

Wenn jedoch mehrere Mounts aus demselben NFS-Export durchgeführt werden und versucht wird, den SELinux-Kontext jedes Mounts durch einen jeweils anderen Kontext zu überschreiben, blockiert das System mit einem Superblock-Fehler ("Same superblock, different security settings").

Um dasselbe Unterverzeichnis eines Exports mehrfach mit unterschiedlichen Kontexten einzuhängen, muss zwingend die Option nosharecache verwendet werden:

sudo mount server:/export/web /local/web -o nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
sudo mount server:/export/database /local/database -o nosharecache,context="system_u:object_r:mysqld_db_t:s0"

Dauerhafte Kontext-Mounts

Kontext-Mounts dauerhaft machen (Persistenz)

Da Befehle wie mount -o context=... temporär sind und Systemneustarts nicht überleben, müssen die Optionen in der Datei /etc/fstab oder in einer Automounter-Zuordnung eingetragen werden, um sie persistent zu machen.

Beispiel für einen Eintrag in der /etc/fstab für eine NFS-Kontext-Einbindung:

server:/export /local/mount/ nfs context="system_u:object_r:httpd_sys_content_t:s0" 0 0

Wiederherstellung mit restorecon

Wiederherstellung korrekter Labels

Relabeling mit restorecon

Arbeitsablauf von restorecon

1. Das Werkzeug übernimmt einen Zielpfad und liest die aktive SELinux-Policy bzw. die zugehörige File-Context-Datenbasis
2. Der Zielpfad wird gegen die regulären Ausdrücke aus der Policy-Datenbasis abgeglichen
3. Das Werkzeug liest den tatsächlich gesetzten erweiterten Dateiattributwert (xattr) des Objekts direkt aus dem Dateisystem
4. Anschließend erfolgt ein Vergleich zwischen dem laut Policy erwarteten Kontext und dem tatsächlich gesetzten Label (Attribut) des Objekts
5. 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

Betriebsarten

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

Veraltender Ansatz

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

Einsatz erzwingen

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

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 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

fixfiles

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/www
chcon -R -t shadow_t /srv
fixfiles 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

← Zurück

Weiter →