Linux/SELinux/Praxis/1 Sicherheitskontext

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

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

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

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

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.

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.

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

Ausgabe

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

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

Ausgabe
<syntaxhighlight lang="bash" highlight="1" line copy>
 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
<syntaxhighlight lang="bash" highlight="1" line copy>
 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*

Ausgabe

 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

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

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
<syntaxhighlight lang="bash" highlight="1" line copy>
 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

chcon

Beschreibung

Der Befehl chcon (change context) wird verwendet, um den SELinux-Kontext einer Datei oder eines Verzeichnisses direkt zu ändern

• Er kann den vollständigen Kontext auf einmal setzen, nur einzelne Kontextfelder (zum Beispiel den Typ) ändern oder mit --reference den Kontext einer anderen Datei übernehmen

Zuvor haben wir in den vorherigen Lektionen bereits die Werkzeuge 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 Parameter -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 der Parameter --reference=RFILE verwendet werden

 touch /tmp/ref
 chcon -R --reference=/tmp/ref /tmp/web_content
 ls -Z -1

Abschließend sollten noch die Parameter für den Umgang mit Symlinks erwähnt werden

• --dereference (standardmäßig verwendet): wirkt nicht auf den symbolischen Link selbst, sondern auf das Objekt, auf das er verweist
• --no-dereference, -h: ändert den symbolischen Link selbst und nicht das Zielobjekt