Überblick
Sobald im Linux-Umfeld restriktive Sicherheitsrichtlinien greifen, wird chcon (change context) zum unverzichtbaren Werkzeug für Ad-hoc-Modifikationen des SELinux-Sicherheitskontexts. Dieser Leitfaden beleuchtet vier praxisnahe Einsatzszenarien für Administratoren und zeigt auf, weshalb temporäre Änderungen bei Systemstarts oder Wartungsarbeiten unerwartet überschrieben werden können.
Status prüfen und grundlegende Syntax von chcon
Für eine isolierte Testumgebung legen wir zunächst ein eigenes Verzeichnis an und wechseln direkt dorthin: mkdir -p /tmp/chcon_lab && cd /tmp/chcon_lab.

Anschließend erzeugen wir mittels touch web_sample.html eine Beispieldatei, die als Anschauungsobjekt für unsere Kontextanalysen dient.

Mit dem Befehl ls -Z web_sample.html lässt sich das aktuell zugewiesene SELinux-Label inspizieren.
Taucht in der Konsole anstelle des Labels lediglich ein Fragezeichen (?) auf, bedeutet dies, dass SELinux auf der Host-Maschine deaktiviert ist oder das Dateisystem keine Sicherheitsattribute hinterlegt hat.
Der generelle Aufruf zur Modifikation von Dateilabels folgt dem Schema chcon [OPTIONEN] KONTEXT DATEI.
⚙️ [Zentrale Optionen]
-t : Ändert gezielt den Typ (Type) des Sicherheitskontexts für Dateien oder Ordner.-u : Weist dem Kontext eine neue Benutzeridentität (User) zu.-r : Definiert die zugewiesene Rolle (Role) innerhalb des Modells neu.-R : Wendet Kontextänderungen rekursiv auf Verzeichnishierarchien an.--reference : Übernimmt das Sicherheitslabel einer bestehenden Referenzdatei eins zu eins.-v : Liefert im Terminal eine ausführliche Statusmeldung über jede vorgenommene Anpassung.

Gezielte Anpassung des SELinux-Typs (-t) im Praxiseinsatz
Um die Bereitstellung von Webinhalten unter restriktiven Richtlinien zu simulieren, bereiten wir mit mkdir -p /tmp/chcon_lab && touch /tmp/chcon_lab/index.html einen Webordner samt Testdatei vor.

Damit HTTP-Dienste wie Apache oder Nginx Lesezugriff auf statische Ressourcen erhalten, weisen wir der Zieldatei mit chcon -t httpd_sys_content_t /tmp/chcon_lab/index.html den Typ httpd_sys_content_t zu.

Die Überprüfung der getätigten Einstufung erfolgt über ls -Z /tmp/chcon_lab/index.html.
Wird in der Ausgabe ein ? ausgegeben, operiert das System ohne aktives SELinux, sodass das Dateisystem keine erweiterten Sicherheitsattribute abbildet.

Referenzabgleich (–reference) und rekursive Vererbung (-R)
Für die Demonstration hierarchischer Berechtigungsvergaben legen wir einen Unterordner mit Stylesheet über mkdir -p /tmp/chcon_lab/public_html && touch /tmp/chcon_lab/public_html/style.css an.

Als Zielobjekt für den Musterabgleich erstellen wir mit touch /tmp/chcon_lab/target_page.html eine weitere HTML-Datei.

Anstatt Kontextzeichenketten fehleranfällig manuell einzutippen, spiegeln wir das vollständige Label der bestehenden index.html via chcon --reference=/tmp/chcon_lab/index.html /tmp/chcon_lab/target_page.html direkt auf target_page.html.
Der Parameter --reference garantiert konsistente Einstellungen, indem er geprüfte Sicherheitsattribute einer Vorlage als Schablone übernimmt.

Sollen ganze Verzeichnisbäume vereinheitlicht werden, überträgt chcon -R -t httpd_sys_content_t /tmp/chcon_lab/public_html den gewünschten Typ httpd_sys_content_t auf sämtliche Ordner und darin enthaltene Dateien.
Das Flag -R sorgt hierbei für einen vollständigen rekursiven Durchlauf der gesamten Dateihierarchie.

Ein detaillierter Überblick über die Attribute im Verzeichnis lässt sich über ls -laZ /tmp/chcon_lab/public_html abrufen.
Zeigt die Terminalausgabe ein ?, arbeitet das Betriebssystem mit inaktivem SELinux-Subsystem, weshalb keine Sicherheitskontexte vorgehalten werden.

Wesentliche Limitierungen und Risiken beim Einsatz von chcon
Um Hilfsprogramme wie restorecon für die Rücksetzung von Sicherheitsattributen bereitzustellen, installieren wir die Core-Utilities mit apt-get update -qq && apt-get install -y policycoreutils.

Für die Rücksetzungsprüfung erzeugen wir mit touch /tmp/chcon_lab/warning_test.txt ein separates Testdokument.

Über chcon -t tmp_t /tmp/chcon_lab/warning_test.txt setzen wir den Sicherheitskontext provisorisch auf den Typ tmp_t.
Hierbei gilt es zu beachten: Modifikationen durch chcon sind flüchtig und werden nicht in der zentralen SELinux-Richtliniendatenbank persistiert.

Ein Aufruf von ls -Z /tmp/chcon_lab/warning_test.txt veranschaulicht den aktuellen Zustand der Datei.
Wird an dieser Stelle ? zurückgegeben, ist SELinux auf dem Host deaktiviert, weshalb das Labeling nicht greift.

Mit dem Befehl restorecon -v /tmp/chcon_lab/warning_test.txt setzen wir die Datei auf die standardmäßig in der Systemrichtlinie definierten Werte zurück.
Jegliche via chcon gesetzten Werte gehen bei einem manuellen restorecon-Aufruf oder einem automatischen Dateisystem-Relabeling (autorelabel) verloren. Dauerhafte, rebootfeste Zuordnungen erfordern zwingend die Konfiguration mittels semanage fcontext.

Abschließend überprüfen wir das Ergebnis der Rücksetzung erneut per ls -Z /tmp/chcon_lab/warning_test.txt.
Auch hier verweist ein ? im Output auf einen inaktiven Zustand der SELinux-Umgebung.

Damit haben wir die flexible Steuerung von SELinux-Sicherheitskontexten mit dem Befehl chcon sowie dessen temporären Charakter praxisnah beleuchtet.
Für kurzzeitiges Debugging leistet das Kommando hervorragende Dienste – bei produktiven Dauerinstallationen sollten Sie jedoch stets auf persistente Richtlinienmechanismen setzen.