Zum Inhalt springen

Linux/SELinux/04/07 Kontexte

Aus Foxwiki

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

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

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

Kopieren/Verschieben

Verhalten beim Kopieren (cp) und Verschieben (mv)

In diesem Abschnitt wird das Verhalten des Kontexts beim Kopieren und Verschieben von Dateien gezeigt

Zunächst ist wichtig zu verstehen, dass bei der Beibehaltung des Kontexts bei der Arbeit mit Dateien — zum Beispiel beim Verschieben — ein normaler Benutzer nur den Namensraum user.* überträgt, während der Superuser alle Namensräume außer system.* kopiert

In der Praxis bedeutet das, dass die Beibehaltung von SELinux-Labels über xattr in der Regel Root-Rechte erfordert

  • In dieser Lektion arbeiten wir ausschließlich als Benutzer root

Kopieren einer Datei

Für einen sauberen Versuch erstellen wir ein temporäres Verzeichnis, das ein Webserver-Verzeichnis simuliert, und weisen ihm den passenden Kontext zu

 mkdir /tmp/web_root
 chcon -t httpd_sys_content_t /tmp/web_root
 ls -Zd /tmp/web_root

Nun erstellen wir zwei identische Testdateien im gewöhnlichen Verzeichnis /tmp (wo Dateien standardmäßig mit dem Kontext user_tmp_t angelegt werden)

 touch /tmp/file_to_copy
 touch /tmp/file_to_move
 ls -Z -1 /tmp/file_to_*
Ausgabe
 sudo ls -Z -1 /tmp/file_to_*
 unconfined_u:object_r:user_tmp_t:s0 /tmp/file_to_copy
 unconfined_u:object_r:user_tmp_t:s0 /tmp/file_to_move

Wir kopieren die erste Datei in unser „Web-Verzeichnis“ und sehen uns das Ergebnis an

 cp /tmp/file_to_copy /tmp/web_root/
 ls -Z /tmp/web_root/file_to_copy
Ausgabe
 sudo ls -Z /tmp/web_root/file_to_copy
 unconfined_u:object_r:httpd_sys_content_t:s0 /tmp/web_root/file_to_copy

Die Datei hat ihren Typ auf httpd_sys_content_t geändert

Das Werkzeug cp erstellt auf dem Datenträger eine vollständig neue Datei (einen neuen inode)

  • Nach den SELinux-Regeln erbt jede neue Datei standardmäßig den Kontext ihres Elternverzeichnisses
  • Das Verzeichnis /tmp/web_root/ hat den Typ für Web-Inhalte, deshalb wurde auch die neue Datei als Web-Inhalt markiert
  • Der Webserver wird sie lesen können

Verschieben einer Datei

Nun verschieben wir die zweite Datei und prüfen ihren Kontext

 mv /tmp/file_to_move /tmp/web_root/
 ls -Z /tmp/web_root/file_to_move
Ausgabe
 sudo ls -Z /tmp/web_root/file_to_move
 unconfined_u:object_r:user_tmp_t:s0 /tmp/web_root/file_to_move

Die Datei hat ihren alten Typ user_tmp_t beibehalten

Das Werkzeug mv erstellt (bei einem Verschieben innerhalb desselben Dateisystems) keine neue Datei

  • Es ändert lediglich den Verzeichniseintrag, also die Zuordnung der Datei von einem Verzeichnis in ein anderes
  • Die Datei bleibt physisch dieselbe, und alle ihre erweiterten Attribute (einschließlich des SELinux-Labels) „wandern“ zusammen mit ihr
  • Der Webserver wird sie nicht lesen können und einen Zugriffsfehler liefern

Verhalten steuern

Attribute beibehalten

Kopieren unter Beibehaltung der Attribute

Für verschiedene Zwecke, zum Beispiel zum Schutz wichtiger Daten oder für Backups, kann es erforderlich sein, den Kontext beim Kopieren vollständig beizubehalten

Dafür wird das Flag --preserve=context (oder der Archivmodus -a) verwendet

Wir erstellen eine Testdatei

 touch /tmp/important_file
 chcon -t shadow_t /tmp/important_file

Wir kopieren sie mit ausdrücklicher Anweisung, den SELinux-Kontext beizubehalten

 cp --preserve=context /tmp/important_file /tmp/web_root/important_backup

oder

 cp -a /tmp/important_file /tmp/web_root/important_backup

Prüfung
<syntaxhighlight lang="bash" highlight="1" line copy>
 ls -Z /tmp/web_root/important_backup

Damit zwingen wir cp, nicht nur den Dateiinhalt, sondern auch die erweiterten Sicherheitsattribute zu kopieren

  • Das ist bei der Erstellung von Backups von entscheidender Bedeutung

Verschieben mit Vererbung

Wir haben die Dateien einer Website nach /tmp heruntergeladen und wollen sie nach /var/www/html verschieben, damit sie sofort den korrekten Web-Kontext erhalten und die Website ohne 403-Forbidden-Fehler funktioniert

Variante 1 Flag -Z

Werkzeuge aus der coreutils-Familie sind in modernen Linux-Distributionen gut über SELinux informiert

  • Ein großes -Z veranlasst den Befehl mv, das System unmittelbar zu fragen: „Welcher Kontext sollte hier standardmäßig gesetzt werden?“ und diesen dann anzuwenden.

    Die Standardkontexte für Verzeichnisse werden in einer Datenbank gespeichert und mit dem Werkzeug semanage verwaltet; eine ausführliche Besprechung folgt in späteren Lektionen

  • In diesem Beispiel verwenden wir das Verzeichnis /var/www/html mit dem Standardkontext httpd_sys_content_t anstelle von /tmp/web_root, weil die SELinux-Datenbank keinen Eintrag dafür hat, welcher Standardkontext für /tmp/web_root gesetzt werden soll.

Wir bereiten die benötigte Datei vor

 touch /tmp/site_index.html

Wir verschieben sie mit dem Flag -Z
<syntaxhighlight lang="bash" highlight="1" line copy>
 mv -Z /tmp/site_index.html /var/www/html/

Prüfung

 ls -Z /var/www/html/site_index.html

Ausgabe

 sudo ls -Z /var/www/html/site_index.html
 unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/site_index.html

Die Datei wurde physisch verschoben, aber ihr SELinux-Label wurde automatisch gemäß den Standardregeln des neuen Verzeichnisses neu gesetzt

Variante 2 Kontext wiederherstellen

Das Flag -Z kann man leicht einmal vergessen

  • Für solche Fälle gibt es die Möglichkeit, den Kontext mit dem Werkzeug restorecon (restore context) auf das Standardlabel zurückzusetzen

Wir erstellen eine weitere Datei und verschieben sie auf klassische Weise, also ohne Vererbung

 touch /tmp/another_file.html
 ls -Z /tmp/another_file.html
 mv /tmp/another_file.html /var/www/html/

Wiederherstellung des Labels

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

Ausgabe

 sudo restorecon -v /var/www/html/another_file.html
 Relabeled /var/www/html/another_file.html from unconfined_u:object_r:user_tmp_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0

Das Werkzeug restorecon ist in Systemen mit SELinux ein nützliches Hilfsmittel zur Diagnose von Problemen nach dem Verschieben von Dateien in Systemverzeichnisse

  • Der Parameter -v wird verwendet, um Details auf der Konsole auszugeben

Verschieben mit rsync

Zunächst ist wichtig zu beachten, dass rsync -a weder ACLs noch erweiterte Attribute xattr einschließt

Die Option -X veranlasst rsync, erweiterte Attribute beizubehalten

Zur Festigung erstellen wir ein Dateipaar

 touch rsynced1 && touch rsynced2

Wir versuchen, sie auf verschiedene Arten in das Verzeichnis /tmp/web_root zu verschieben

rsync -a rsynced1 /tmp/web_root/
rsync -aX rsynced2 /tmp/web_root/
ls -Z -1 /tmp/web_root/rsy*
sudo ls -Z -1 /tmp/web_root/rsy*
unconfined_u:object_r:httpd_sys_content_t:s0 /tmp/web_root/rsynced1
unconfined_u:object_r:user_home_t:s0 /tmp/web_root/rsynced2
Befehl Beschreibung
rsync -a überträgt Standardattribute
rsync -A überträgt ACLs
rsync -X überträgt xattrs

In der Praxis wird für Backups am häufigsten der universelle Befehl rsync -aHAX verwendet, der alle Attributarten einschließt; dabei steht die Option H für Hardlinks

Die häufigsten Probleme bei der Arbeit von rsync mit Attributen hängen mit einer Ausführung ohne ausreichende Privilegien zusammen

  • Abschließend ist wichtig zu erwähnen, dass security.selinux von NFS möglicherweise nicht unterstützt wird, da dort eine ältere xattr-Semantik verwendet wird

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

  1. 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
  2. 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

  1. Regulärer Ausdruck (Regular Expression). Die erste Spalte beschreibt den Pfad
    • SELinux verwendet reguläre Ausdrücke im PCRE*-Format
    • Beispielsweise bedeutet der Ausdruck /var/www(/.*)?: sowohl das Verzeichnis /var/www selbst als auch absolut jede Datei oder jedes Unterverzeichnis darin
    • Ausführlicher über reguläre Ausdrücke sprechen wir in den nächsten Lektionen
  2. 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.
  3. 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

  1. 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
  2. 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(/.*)?
  3. 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

  1. 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
  2. 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
  3. 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

Archivierung und chcon

Archivierung

Archivierungsprogramme ignorieren standardmäßig xattr

Wenn man versucht, mit dem üblichen Befehl tar -cvf ein Backup einer Website zu erstellen und dieses anschließend auf einem anderen Server zu entpacken, gehen alle Labels verloren

  • Die entpackten Dateien erhalten einen zufälligen Kontext des aktuellen Verzeichnisses, und der Webserver gibt einen Fehler 403 zurück

Damit tar Dateien zusammen mit ihren Sicherheitslabels archiviert und wieder entpackt, muss dies explizit über die entsprechenden Parameter angegeben werden

Erstellen eines Backups unter Beibehaltung der Kontexte

tar --xattrs --selinux -cvf website_backup.tar /var/www/html

Prüfen, ob xattr vorhanden ist

tar --selinux -tvf website_backup.tar

Entpacken

 tar --xattrs --selinux -xvf website_backup.tar -C /tmp/restore_dir/

Wichtig: Das Dienstprogramm zip sowie viele andere Archivierungsprogramme unterstützen SELinux nicht

Für die Arbeit mit Labels sollte daher tar (oder alternativ star) verwendet werden

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


SELinux-Kontexte – Dateien kennzeichnen

Auf Systemen, auf denen SELinux läuft, werden alle Prozesse und Dateien so gekennzeichnet, dass sie sicherheitsrelevante Informationen darstellen

  • Diese Informationen werden als SELinux-Kontext bezeichnet
  • Bei Dateien kann dies mit dem Befehl ls -Z angezeigt werden
ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

In diesem Beispiel stellt SELinux einen Benutzer (unconfined_u), eine Rolle (object_r), einen Typ (user_home_t) und eine Stufe (s0) bereit

  • Diese Informationen werden verwendet, um Entscheidungen zur Zugriffskontrolle zu treffen
  • Auf DAC-Systemen wird der Zugriff auf Basis der Linux-Benutzer- und Gruppen-IDs kontrolliert
  • SELinux-Richtlinienregeln werden nach den DAC-Regeln überprüft
  • SELinux-Richtlinienregeln werden nicht angewendet, wenn DAC-Regeln den Zugriff zuvor verweigern
Hinweis
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, erbt die neue Datei denselben Typ
ls -dZ - /etc
drwxr-xr-x root root system_u:object_r:‚'etc_t‘':s0 /etc
sudo touch /etc/file1
sudo ls -lZ /etc/file1
-rw-r--r-- root root unconfined_u:object_r:‚'etc_t‘':s0 /etc/file1

SELinux bietet mehrere Befehle zur Verwaltung der Dateisystem-Kennzeichnung, wie beispielsweise chcon, semanage fcontext, restorecon und matchpathcon

Temporäre Änderungen: chcon

Der Befehl chcon ändert den SELinux-Kontext für Dateien

  • Änderungen, die mit dem Befehl chcon vorgenommen werden, bleiben jedoch nicht bestehen, wenn das Dateisystem neu gekennzeichnet wird oder der Befehl restorecon
  • Die SELinux-Richtlinie legt fest, ob Benutzer den SELinux-Kontext für eine bestimmte Datei ändern dürfen
  • Bei der Verwendung von chcon geben Benutzer den gesamten oder einen Teil des SELinux-Kontexts an, der geändert werden soll
  • Ein falscher Dateityp ist eine häufige Ursache dafür, dass SELinux den Zugriff verweigert

Kurzreferenz

  • Führen Sie den Befehl chcon -t ‚'type‘' ‚'file-name‘' , um den Dateityp zu ändern, wobei ‚'type‘' ein SELinux-Typ ist, wie z. B. [ [httpd_sys_content_t]], und ‚'file-name‘' ein Datei- oder Verzeichnisname ist
chcon -t httpd_sys_content_t ‚'file-name‘'
chcon -R -t httpd_sys_content_t ‚'Verzeichnisname‘'
Ändern des Typs einer Datei oder eines Verzeichnisses

Das folgende Verfahren zeigt, wie der Typ und keine anderen Attribute des SELinux-Kontexts geändert werden

  • Das Beispiel in diesem Abschnitt funktioniert genauso für Verzeichnisse, beispielsweise wenn file1 ein Verzeichnis wäre. # Wechseln Sie in Ihr Home-Verzeichnis
  1. Erstellen Sie eine neue Datei und zeigen Sie deren SELinux-Kontext an
touch file1
ls -Z file1
-rw -rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

In diesem Beispiel umfasst der SELinux-Kontext für file1 den SELinux-Benutzer unconfined_u, die Rolle object_r, den Typ user_home_t und die s0 Ebene

  • Eine Beschreibung der einzelnen Bestandteile des SELinux-Kontexts finden Sie in Kapitel 2, ‚'SELinux-Kontexte‘'
  1. Geben Sie den folgenden Befehl ein, um den Typ in samba_share_t zu ändern
  • Die Option -t ändert nur den Typ
  • Zeigen Sie anschließend die Änderung an
chcon -t samba_share_t file1
ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:samba_share_t:s0 file1
  1. Verwenden Sie den folgenden Befehl, um den SELinux-Kontext für die Datei file1 wiederherzustellen
  • Verwenden Sie die Option -v, um die Änderungen anzuzeigen
restorecon -v file1
restorecon reset file1 context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:user_home_t:s0

In diesem Beispiel wird der vorherige Typ, samba_share_t, auf den korrekten Typ, user_home_t, zurückgesetzt

  • Bei Verwendung der Targeted-Richtlinie (der Standard-SELinux-Richtlinie in Red Hat Enterprise Linux) liest der Befehl restorecon die Dateien im Verzeichnis /etc/selinux/targeted/contexts/files/ aus, um festzustellen, welchen SELinux-Kontext die Dateien haben sollten
Ändern der Typen eines Verzeichnisses und seines Inhalts

Das folgende Beispiel zeigt, wie ein neues Verzeichnis erstellt und der Dateityp des Verzeichnisses sowie dessen Inhalt auf einen vom Apache-HTTP-Server verwendeten Typ geändert wird

  • Die Konfiguration in diesem Beispiel wird verwendet, wenn Sie möchten, dass der Apache-HTTP-Server ein anderes Dokumentstammverzeichnis (anstelle von /var/www/html/) verwendet
  1. Erstellen Sie als Root-Benutzer ein neues [ [web/]]-Verzeichnis und anschließend 3 leere Dateien (file1, file2 und file3) in diesem Verzeichnis
  • Das web/-Verzeichnis und die darin enthaltenen Dateien sind mit dem Typ default_t gekennzeichnet
sudo mkdir /web

sudo touch /web/file{1,2,3}

sudo ls -dZ /web
drwxr-xr-x root root unconfined_u:object_r:default_t:s0 /web
sudo ls -lZ /web

-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file1

-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file2

-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file3

  1. Geben Sie als root den folgenden Befehl ein, um den Typ des Verzeichnisses web/ (und dessen Inhalt) in httpd_sys_content_t zu ändern
sudo chcon -R -t httpd_sys_content_t /web/
sudo ls -dZ /web/
drwxr-xr-x root root unconfined_u:object_r:httpd_sys_content_t:s0 /web/

sudo ls -lZ /web/

-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0 file2
-rw-r--r-- root root unconfined_u:object_r: httpd_sys_content_t:s0 file3
  1. Um die Standard-SELinux-Kontexte wiederherzustellen, verwenden Sie das Dienstprogramm restorecon als root
sudo restorecon -R -v /web/
restorecon reset /web context unconfined_u:object_r:httpd_sys_content_t:s0->system_u:object_r:default_t:s0

restorecon reset /web/file2 context unconfined_u:object_r:httpd_sys_content_t:s0->system_u:object_r:default_t:s0

restorecon reset /web/file3 context unconfined_u:object_r:httpd_sys_content_t:s0->system_u:object_r:default_t: s0
restorecon reset /web/file1 context unconfined_u:object_r:httpd_sys_content_t:s0->system_u:object_r:default_t:s0

Weitere Informationen zu chcon finden Sie auf der chcon(1)-Manpage

Hinweis
Typen-Enforcement 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

Dauerhafte Änderungen: semanage fcontext

Der Befehl semanage fcontext wird verwendet, um den SELinux-Kontext von Dateien zu ändern

  • Um die Kontexte neu erstellter Dateien und Verzeichnisse anzuzeigen, geben Sie als root den folgenden Befehl ein
sudo semanage fcontext -C -l

Änderungen, die mit semanage fcontext vorgenommen wurden, werden von den folgenden Dienstprogrammen verwendet

  • Das Dienstprogramm setfiles wird verwendet, wenn ein Dateisystem neu gekennzeichnet wird, und das Dienstprogramm restorecon stellt die Standard-SELinux-Kontexte wieder her
  • Das bedeutet, dass durch semanage fcontext vorgenommene Änderungen dauerhaft sind, selbst wenn das Dateisystem neu gekennzeichnet wird
  • Die SELinux-Richtlinie steuert, ob Benutzer den SELinux-Kontext für eine bestimmte Datei ändern können

Kurzübersicht

Um SELinux-Kontextänderungen vorzunehmen, die eine Neukennzeichnung des Dateisystems überdauern

  1. Geben Sie den folgenden Befehl ein und achten Sie darauf, den vollständigen Pfad zur Datei oder zum Verzeichnis zu verwenden
sudo semanage fcontext -a ‚'Optionen‘' ‚'Dateiname‘ ‚|‘'Verzeichnisname'‚
  1. Verwenden Sie das Dienstprogramm restorecon, um die Kontextänderungen anzuwenden
sudo restorecon -v ‘'Dateiname'‚|‘'Verzeichnisname'‚
Verwendung regulärer Ausdrücke mit semanage fcontext

Damit der Befehl semanage fcontext korrekt funktioniert, können Sie entweder einen vollqualifizierten Pfad oder ‘ Perl-kompatible reguläre Ausdrücke ()‚‘'

  • Das einzige verwendete ‚'PCRE‘'-Flag ist PCRE2_DOTALL, wodurch der Platzhalter [[.]] mit allem übereinstimmt, einschließlich einer neuen Zeile
  • Zeichenfolgen, die Pfade darstellen, werden als Bytes verarbeitet, was bedeutet, dass Nicht-ASCII-Zeichen nicht durch einen einzelnen Platzhalter abgeglichen werden

Beachten Sie, dass mit semanage fcontext angegebene Dateikontextdefinitionen in umgekehrter Reihenfolge zu ihrer Definition ausgewertet werden der letzte Eintrag wird unabhängig von der Stammlänge zuerst ausgewertet

  • Lokale Dateikontextänderungen, die in file_contexts.local gespeichert sind, haben eine höhere Priorität als die in Policy-Modulen angegebenen
  • Das bedeutet, dass immer dann, wenn in file_contexts.local gefunden wird, werden keine anderen Dateikontextdefinitionen berücksichtigt
Wichtig
Mit dem Befehl semanage fcontext festgelegte Dateikontextdefinitionen überschreiben effektiv alle anderen Dateikontextdefinitionen
  • Alle regulären Ausdrücke sollten daher so spezifisch wie möglich sein, um unbeabsichtigte Auswirkungen auf andere Teile des Dateisystems zu vermeiden

Weitere Informationen zu den in Dateikontextdefinitionen verwendeten regulären Ausdrücken und den geltenden Flags finden Sie in der semanage-fcontext(8) Man-Seite

Ändern des Typs einer Datei oder eines Verzeichnisses

Das folgende Beispiel zeigt, wie der Typ einer Datei geändert wird, ohne andere Attribute des SELinux-Kontexts zu beeinflussen

  • Dieses Beispiel funktioniert genauso für Verzeichnisse, beispielsweise wenn file1 ein Verzeichnis wäre. # Erstellen Sie als Root-Benutzer eine neue Datei im Verzeichnis /etc
  • Standardmäßig werden neu erstellte Dateien in /etc mit dem Typ etc_t gekennzeichnet
sudo touch /etc/file1

ls -Z /etc/file1

-rw-r--r-- root root unconfined_u:object_r:etc_t:s0 /etc/file1

Um Informationen zu einem Verzeichnis aufzulisten, verwenden Sie den folgenden Befehl

ls -dZ ‚'Verzeichnisname‘'
  1. Geben Sie als root den folgenden Befehl ein, um den Typ von file1 in samba_share_t zu ändern
  • Die Option -a fügt einen neuen Eintrag hinzu, und die Option -t definiert einen Typ (samba_share_t)
  • Beachten Sie, dass die Ausführung dieses Befehls den Typ nicht direkt ändert; file1 ist weiterhin mit dem Typ etc_t gekennzeichnet
sudo semanage fcontext -a -t samba_share_t /etc/file1
sudo ls -Z /etc/file1
-rw-r--r-- root root unconfined_u:object_r:etc_t:s0 /etc/file1
semanage fcontext -C -l

/etc/file1 unconfined_u:object_r:samba_share_t:s0

  1. Verwenden Sie als root das Dienstprogramm restorecon, um den Typ zu ändern
sudo restorecon -v /etc/file1
restorecon reset /etc/file1 context unconfined_u:object_r:etc_t:s0->system_u:object_r:samba_share_t:s0
Ändern der Typen eines Verzeichnisses und seines Inhalts

Das folgende Beispiel zeigt, wie ein neues Verzeichnis erstellt und der Dateityp des Verzeichnisses sowie dessen Inhalt auf einen vom Apache-HTTP-Server verwendeten Typ geändert wird

  • Die Konfiguration in diesem Beispiel wird verwendet, wenn Sie möchten, dass der Apache-HTTP-Server anstelle von [[/var/www/html/] einen anderen Dokumentenstamm verwendet ]
  1. Erstellen Sie als Root-Benutzer ein neues Verzeichnis web/ und anschließend 3 leere Dateien (file1, file2 und file3) in diesem Verzeichnis
  • Das Verzeichnis web/ und die darin enthaltenen Dateien sind mit dem Typ default_t gekennzeichnet
sudo mkdir /web
sudo touch /web/file{1,2,3}
sudo ls -dZ /web
drwxr-xr-x root root unconfined_u:object_r:default_t:s0 /web
sudo ls -lZ /web
-rw-r--r-- root root unconfined_ u:object_r:default_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file2
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file3
  1. Geben Sie als root den folgenden Befehl ein, um den Typ des web/-Verzeichnisses und der darin enthaltenen Dateien in httpd_sys_content_t zu ändern
  • Die Option -a fügt einen neuen Eintrag hinzu, und die Option -t definiert einen Typ (httpd_sys_content_t)
  • Der reguläre Ausdruck [[„/web(/.*)?“] ] bewirkt, dass semanage die Änderungen auf web/ sowie die darin enthaltenen Dateien anwendet
  • Beachten Sie, dass die Ausführung dieses Befehls den Typ nicht direkt ändert; web/ und die darin enthaltenen Dateien sind weiterhin mit dem Typ default_t gekennzeichnet
sudo semanage fcontext -a -t httpd_sys_content_t „/web(/.*)?“
ls -dZ /web

drwxr-xr-x root root unconfined_u:object_r:default_t:s0 /web

ls -lZ /web
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file1
-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file2

-rw-r--r-- root root unconfined_u:object_r:default_t:s0 file3

Der Befehl semanage fcontext -a -t httpd_sys_content_t „/web(/.*)?“ fügt den folgenden Eintrag zu /etc/selinux/targeted/contexts/files/file_contexts.local hinzu

/web(/.*)? system_u:object_r:httpd_sys_content_t:s0
  1. Verwenden Sie als root das Dienstprogramm restorecon, um den Typ von web/ sowie aller darin enthaltenen Dateien

[httpd_sys_content_t]]

sudo restorecon -R -v /web
restorecon reset /web context unconfined_u:object_r:default_t:s0->system_u:object_r: httpd_sys_content_t:s0
restorecon reset /web/file2 context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /web/file3 context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0

restorecon reset /web/file1 context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0

Beachten Sie, dass neu erstellte Dateien und Verzeichnisse standardmäßig den SELinux-Typ ihrer übergeordneten Verzeichnisse erben

Einen hinzugefügten Kontext löschen

Das folgende Beispiel zeigt das Hinzufügen und Entfernen eines SELinux-Kontexts

  • Wenn der Kontext Teil eines regulären Ausdrucks ist, zum Beispiel /web(/.*)?, setzen Sie den regulären Ausdruck in Anführungszeichen
sudo semanage fcontext -d „/web(/.*)?“
  1. Um den Kontext zu entfernen, geben Sie als Root den folgenden Befehl ein, wobei ‚'Dateiname‘'|‚'Verzeichnisname‘' der erste Teil in file_contexts.local ist
sudo semanage fcontext -d ‚'Dateiname‘'|‚'Verzeichnisname‘'

Das Folgende ist ein Beispiel für einen Kontext in file_contexts. local

/test system_u:object_r:httpd_sys_content_t:s0

wobei der erste Teil test ist

  • Um zu verhindern, dass das Verzeichnis test/ nach dem Ausführen von restorecon oder nach einer Neulabelung des Dateisystems mit dem httpd_sys_content_t-Label versehen wird, geben Sie als Root den folgenden Befehl ein, um den Kontext aus file_contexts.local zu löschen
sudo semanage fcontext -d /test
  1. Verwenden Sie als root das Dienstprogramm restorecon, um den Standard-SELinux-Kontext wiederherzustellen

Weitere Informationen zu semanage finden Sie in den Handbuchseiten semanage(8) und semanage-fcontext(8)

Wichtig
Wenn Sie den SELinux-Kontext mit semanage fcontext -a ändern, verwenden Sie den vollständigen Pfad zur Datei oder zum Verzeichnis, um zu vermeiden, dass Dateien nach einer Neukennzeichnung des Dateisystems oder nach dem Ausführen des Befehls [

[restorecon]]-Befehls

Wie der Dateikontext bestimmt wird

Die Bestimmung des Dateikontexts basiert auf Dateikontextdefinitionen, die in der Systemsicherheitsrichtlinie (den .fc-Dateien) festgelegt sind

Systemadministratoren können Dateikontextdefinitionen mit dem Befehl semanage fcontext anpassen

Wenn ein Kennzeichnungsprogramm wie matchpathcon oder restorecon die richtige Kennzeichnung für einen bestimmten Pfad ermittelt, sucht es zunächst nach lokalen Änderungen (file_contexts.local)

  • Findet das Dienstprogramm kein passendes Muster, durchsucht es die Datei file_contexts.homedirs und schließlich die Datei file_contexts
  • Sobald jedoch eine Übereinstimmung für einen bestimmten Dateipfad gefunden wird, endet die Suche, sucht das Dienstprogramm nicht nach weiteren Dateikontext-Definitionen
  • Das bedeutet, dass Dateikontexte, die sich auf das Home-Verzeichnis beziehen, eine höhere Priorität haben als die übrigen, und lokale Anpassungen überschreiben die Systemrichtlinie

Dateikontext-Definitionen, die durch die Systemrichtlinie festgelegt sind (Inhalt der Dateien file_contexts.homedirs und file_contexts), werden vor der Auswertung nach der Länge des Stamms (Präfix des Pfads vor etwaigen Platzhaltern) sortiert

  • Das bedeutet, dass der spezifischste Pfad ausgewählt wird
  • Mit semanage fcontext festgelegte Dateikontextdefinitionen werden jedoch in umgekehrter Reihenfolge zu ihrer Definition ausgewertet

der letzte Eintrag wird unabhängig von der Stammlänge zuerst ausgewertet

Weitere Informationen zu

  • der Änderung des Dateikontexts mit chcon finden Sie im Abschnitt „Temporäre Änderungen

chcon“

  • das Ändern und Hinzufügen einer Dateikontextdefinition mit semanage fcontext finden Sie im Abschnitt „ Dauerhafte Änderungen

semanage fcontext“