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

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 /

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