Linux/SELinux/04/09 Dateisysteme

Debian

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

Wiederherstellung korrekter Labels

Relabeling mit restorecon

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

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

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

RHEL

Einbinden von Dateisystemen

Standardmäßig wird beim Einbinden eines Dateisystems, das erweiterte Attribute unterstützt, der Sicherheitskontext für jede Datei aus dem ‚'security.selinux‘'

erweiterten Attribut der Datei

• Dateien in Dateisystemen, die keine erweiterten Attribute unterstützen, wird ein einziger Standard-Sicherheitskontext aus der Richtlinienkonfiguration zugewiesen, basierend auf dem Dateisystemtyp

Verwenden Sie den Befehl mount -o context, um vorhandene erweiterte Attribute zu überschreiben oder einen anderen Standardkontext für Dateisysteme festzulegen, die keine erweiterten Attribute unterstützen

• Dies ist nützlich, wenn Sie nicht darauf vertrauen, dass ein Dateisystem die richtigen Attribute bereitstellt, beispielsweise bei Wechselmedien, die in mehreren Systemen verwendet werden
• Der Befehl mount -o context kann auch verwendet werden, um die Kennzeichnung für Dateisysteme zu unterstützen, die keine erweiterten Attribute unterstützen, wie z. B. File Allocation Table (FAT) oder NFS-Volumes
• Der mit der Option context angegebene Kontext wird nicht auf die Festplatte geschrieben

die ursprünglichen Kontexte bleiben erhalten und sind beim Einbinden ohne context sichtbar, sofern das Dateisystem ursprünglich über erweiterte Attribute verfügte

Weitere Informationen zur Dateisystem-Kennzeichnung finden Sie in James Morris' Artikel „Filesystem Labeling in SELinux“ http://www.linuxjournal.com/article/7426

Kontext-Mounts

Um ein Dateisystem mit dem angegebenen Kontext zu mounten – wobei vorhandene Kontexte überschrieben werden, falls vorhanden – oder um einen anderen Standardkontext für ein Dateisystem festzulegen, das keine erweiterten Attribute unterstützt, verwenden Sie als Root-Benutzer den mount -o context=‚'SELinux_user:role:type:level‘' beim Einhängen des gewünschten Dateisystems

• Kontextänderungen werden nicht auf die Festplatte geschrieben
• Standardmäßig werden NFS-Einhängungen auf der Client-Seite mit einem Standardkontext gekennzeichnet, der durch die Richtlinie für NFS-Volumes definiert ist
• In gängigen Richtlinien verwendet dieser Standardkontext den Typ nfs_t
• Ohne zusätzliche Mount-Optionen kann dies die Freigabe von NFS-Volumes über andere Dienste, wie den Apache-HTTP-Server, verhindern
• Das folgende Beispiel mountet ein NFS-Volume so, dass es über den Apache-HTTP-Server freigegeben werden kann

sudo mount server:/export /local/mount/point -o \ context="system_u:object_r:httpd_sys_content_t:s0"

Neu erstellte Dateien und Verzeichnisse auf diesem Dateisystem scheinen den mit -o context angegebenen SELinux-Kontext zu haben

• Da diese Änderungen jedoch nicht auf die Festplatte geschrieben werden, bleibt der mit dieser Option angegebene Kontext zwischen den Mountvorgängen nicht erhalten
• Daher muss diese Option bei jedem Mountvorgang mit demselben Kontext verwendet werden, um den erforderlichen Kontext beizubehalten
• Informationen dazu, wie man Kontext-Mounts dauerhaft macht, finden Sie im Abschnitt „Kontext-Mounts dauerhaft machen“

Die Typen-Durchsetzung ist die wichtigste Berechtigungssteuerung, die in der SELinux-Targeted-Policy verwendet wird

• In den meisten Fällen können SELinux-Benutzer und -Rollen ignoriert werden. Verwenden Sie daher beim Überschreiben des SELinux-Kontexts mit -o context den SELinux-Benutzer system_u und die Rolle object_r und konzentrieren Sie sich auf den Typ
• Wenn Sie nicht die MLS-Policy oder die Multi-Kategorie-Sicherheit verwenden, verwenden Sie die s0-Ebene

Hinweis

Wenn ein Dateisystem mit einer context-Option eingebunden wird, sind Kontextänderungen durch Benutzer und Prozesse untersagt

• Wenn Sie beispielsweise den Befehl chcon auf einem mit einer context-Option eingebundenen Dateisystem ausführen, führt dies zu einem Fehler Operation not supported

Ändern des Standardkontexts

Wie in Abschnitt 4.8, „Die Typen file_t und default_t“ , wird auf Dateisystemen, die erweiterte Attribute unterstützen, beim Zugriff auf eine Datei, der auf der Festplatte ein SELinux-Kontext fehlt, so behandelt, als hätte sie einen Standardkontext, wie er durch die SELinux-Richtlinie definiert ist

• In gängigen Richtlinien verwendet dieser Standardkontext den Typ file_t
• Wenn ein anderer Standardkontext verwendet werden soll, mounten Sie das Dateisystem mit der Option defcontext

Das folgende Beispiel mountet ein neu erstelltes Dateisystem auf [[/ dev/sda2]] in das neu erstellte Verzeichnis test/ ein

• Dabei wird davon ausgegangen, dass es in /etc/selinux/targeted/contexts/files/ keine Regeln gibt, die einen Kontext für das Verzeichnis test/ definieren

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

In diesem Beispiel

• definiert die Option defcontext, dass system_u:object_r:samba_share_t:s0 „der Standard-Sicherheitskontext für nicht gekennzeichnete Dateien“ ist[5]
• wird das Stammverzeichnis (test/) des Dateisystems nach dem Einbinden so behandelt, als wäre es mit dem durch defcontext angegebenen Kontext gekennzeichnet (diese Kennzeichnung wird nicht auf der Festplatte gespeichert)
• Dies wirkt sich auf die Kennzeichnung von Dateien aus, die unter test/ erstellt werden

neue Dateien erben den Typ samba_share_t, und diese Kennzeichnungen werden auf der Festplatte gespeichert

• Dateien, die unter test/ erstellt wurden, während das Dateisystem mit der Option defcontext eingebunden war, behalten ihre Kennzeichnungen

Einbinden eines NFS-Volumes

Standardmäßig werden NFS-Einbindungen auf der Client-Seite mit einem Standardkontext gekennzeichnet, der durch die Richtlinie für NFS-Volumes definiert ist

• In gängigen Richtlinien verwendet dieser Standardkontext den Typ nfs_t
• Je nach Richtlinienkonfiguration können Dienste wie der Apache-HTTP-Server und MariaDB möglicherweise keine Dateien lesen, die mit dem Typ nfs_t gekennzeichnet sind
• Dies kann verhindern, dass Dateisysteme, die mit diesem Typ gekennzeichnet sind, eingebunden und anschließend von anderen Diensten gelesen oder exportiert werden

Wenn Sie ein NFS-Volume mounten und dieses Dateisystem mit einem anderen Dienst lesen oder exportieren möchten, verwenden Sie beim Mounten die Option context, um den Typ nfs_t zu überschreiben

• Verwenden Sie die folgende context-Option, um NFS-Volumes so einzuhängen, dass sie über den Apache-HTTP-Server freigegeben werden können

sudo mount server:/export /local/mount/point -o context="system_u:object_r:httpd_sys_content_t:s0"

Da diese Änderungen nicht auf die Festplatte geschrieben werden, bleibt der mit dieser Option angegebene Kontext zwischen den Einhängevorgängen nicht erhalten

• Daher muss diese Option bei jedem Einbinden mit demselben Kontext verwendet werden, um den erforderlichen Kontext beizubehalten
• Informationen dazu, wie Kontext-Mounts dauerhaft gemacht werden können, finden Sie im Abschnitt „Kontext-Mounts dauerhaft machen“

Als Alternative zum Einbinden von Dateisystemen mit context-Optionen können Boolesche Werte aktiviert werden, um Diensten den Zugriff auf Dateisysteme zu ermöglichen, die mit dem Typ [ [nfs_t]] gekennzeichnet sind

• Siehe Teil II, „Verwaltung eingeschränkter Dienste“ für Anweisungen zur Konfiguration von Booleans, um Diensten den Zugriff auf den Typ nfs_t zu ermöglichen

Mehrere NFS-Mounts

Wenn mehrere Mounts aus demselben NFS-Export durchgeführt werden und versucht wird, den SELinux-Kontext jedes Mounts durch einen anderen Kontext zu überschreiben, führen nachfolgende Mount-Befehle zu Fehlern

• Im folgenden Beispiel verfügt der NFS-Server über einen einzigen Export, export/, der zwei Unterverzeichnisse enthält: [ [web/]] und database/
• Die folgenden Befehle versuchen zwei Mounts von einem einzigen NFS-Export und versuchen, den Kontext für jeden einzelnen zu überschreiben

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

Der zweite Mount-Befehl schlägt fehl, und Folgendes wird in /var/log/messages protokolliert kernel SELinux mount invalid

• Gleicher Superblock, unterschiedliche Sicherheitseinstellungen für (dev 0:15, Typ nfs)

Um mehrere Mounts aus einem einzigen NFS-Export durchzuführen, wobei jeder Mount einen anderen Kontext hat, verwenden Sie die -o nosharecache,context-Optionen

• Das folgende Beispiel mountet mehrere Mounts aus einem einzigen NFS-Export, wobei jeder Mount einen anderen Kontext hat (wodurch ein einzelner Dienst auf jeden einzelnen zugreifen kann)

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“

In diesem Beispiel wird server:/export/web lokal im Verzeichnis /local/web/ eingebunden, wobei alle Dateien mit dem Typ httpd_sys_content_t gekennzeichnet sind, was dem Apache-HTTP-Server Zugriff gewährt. server:/export/database wird lokal in /local/database/ eingebunden, wobei alle Dateien mit dem Typ [ [mysqld_db_t]] gekennzeichnet, was MariaDB den Zugriff ermöglicht

• Diese Typänderungen werden nicht auf die Festplatte geschrieben

Wichtig

Die Option nosharecache ermöglicht es Ihnen, dasselbe Unterverzeichnis eines Exports mehrfach mit unterschiedlichen Kontexten einzuhängen, beispielsweise /export/web/ mehrfach

• Hängen Sie dasselbe Unterverzeichnis eines Exports nicht mehrfach mit unterschiedlichen Kontexten ein, da dies zu einer überlappenden Einbindung führt, bei der Dateien unter zwei verschiedenen Kontexten zugänglich sind

Kontext-Einbindungen dauerhaft machen

Um Kontext-Mounts über erneutes Mounten und Neustarts hinweg persistent zu machen, fügen Sie Einträge für die Dateisysteme in die Datei /etc/fstab oder eine Automounter-Zuordnung ein und verwenden Sie den erforderlichen Kontext als Mount-Option

Das folgende Beispiel fügt einen Eintrag in /etc/fstab für eine NFS-Kontext-Einbindung hinzu

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

← Zurück

Weiter →