Linux/SELinux/Praxis/1 Sicherheitskontext

Schritt 1.1: Struktur und Auslesen des Sicherheitskontexts

Kontexte / Labels

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:

# 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

---

Anatomie der Kontextzeichenfolge

Das vollständige Label eines Sicherheitskontexts besteht aus vier (manchmal fünf) durch Doppelpunkte getrennten Elementen. Die typische Struktur sieht wie folgt aus:

user : role : type : level

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:

• _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.

Schritt 1.2: Speicherung auf dem Datenträger (Extended Attributes)

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. Genau hier speichert SELinux die Kontextzeichenfolge unter dem Schlüssel security.selinux.

---

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.

Direkte 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 (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 (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.

Praktische Übung

Modus prüfen:

getenforce

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

Erzeugen einer blockierenden Situation

• Stellen wir uns folgende Situation vor: 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

Ausgabe:

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

---

• Prüfung, ob die Attribute korrekt gesetzt wurden:

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

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

• Ausgabe:

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

Schritt 1.3: 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.

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

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

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

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

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

1.3.3 Steuerung dieses Verhaltens

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:

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:

mv -Z /tmp/site_index.html /var/www/html/

• Prüfung:

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

Ausgabe:

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

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

Ausgabe:

# 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

Daraus folgt:

• 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 der Parameter 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.