Foxwiki - Benutzerbeiträge [de]

Dovecot/Imapsieve

2026-07-08T10:19:45Z

DanielZorin:

'''Dovecot/Imapsieve''' Dovecot ''[[imap_sieve]]'' erweitern

== Beschreibung ==
* Beim Kopieren einer Nachricht nach ''Junk'' wird diese an Rspamd als Spam gemeldet
* Beim Kopieren einer Nachricht aus ''Junk'' in einen normalen Ordner wird diese an Rspamd als Ham gemeldet
* Die Konfiguration gilt für Dovecot 2.4

== Konfiguration ==
Custom-Konfiguration
; ISPConfig-Template
Bleib bei späteren Reconfigure-/Update-Vorgängen erhalten

; /usr/local/ispconfig/server/conf-custom/install/dovecot_custom.conf.master
<syntaxhighlight lang="json" copy line>
protocol imap {
mail_plugins {
imap_sieve = yes
}
}

sieve_plugins {
sieve_imapsieve = yes
sieve_extprograms = yes
}

sieve_global_extensions {
vnd.dovecot.pipe = yes
vnd.dovecot.environment = yes
}

sieve_pipe_bin_dir = /etc/dovecot/sieve

mailbox Junk {
sieve_script report-spam {
type = before
cause = copy
path = /etc/dovecot/sieve/report-spam.sieve
}
}

imapsieve_from Junk {
sieve_script report-ham {
type = before
cause = copy
path = /etc/dovecot/sieve/report-ham.sieve
}
}
</syntaxhighlight>

Die ISPConfig-Custom-Konfiguration wird in die aktive Dovecot-Konfiguration übernommen

<syntaxhighlight lang="bash" highlight="1" copy line>
cp /usr/local/ispconfig/server/conf-custom/install/dovecot_custom.conf.master /etc/dovecot/conf.d/99-ispconfig-custom-config.conf
</syntaxhighlight>

; Create sieve scripts folder
<syntaxhighlight lang="bash" highlight="1" copy line>
mkdir -p /etc/dovecot/sieve
</syntaxhighlight>

; /etc/dovecot/sieve/report-spam.sieve
* Die Nachricht wird per Pipe an ''rspamd-learn-spam.sh'' übergeben

<syntaxhighlight lang="console" copy line>
require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "rspamd-learn-spam.sh";
</syntaxhighlight>

; /etc/dovecot/sieve/report-ham.sieve
Dieses Sieve-Skript wird ausgeführt, wenn eine Nachricht aus ''Junk'' in einen anderen IMAP-Ordner kopiert wird
* Kopien nach ''Trash'', ''Deleted Messages'' oder erneut nach ''Junk'' werden ignoriert
* Alle anderen Kopien werden per Pipe an ''rspamd-learn-ham.sh'' übergeben

<syntaxhighlight lang="console" copy line>
require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];

if environment :matches "imap.mailbox" "*" {
set "mailbox" "${1}";
}

if string "${mailbox}" ["Trash", "Deleted Messages", "Junk"] {
stop;
}

pipe :copy "rspamd-learn-ham.sh";
</syntaxhighlight>

; /etc/dovecot/sieve/rspamd-learn-spam.sh
Das Pipe-Skript übergibt die Nachricht an Rspamd und trainiert sie als Spam

<syntaxhighlight lang="bash" copy line>
#!/bin/sh
exec /usr/bin/rspamc -h 10.0.0.8:11334 learn_spam
</syntaxhighlight>

; /etc/dovecot/sieve/rspamd-learn-ham.sh
Das Pipe-Skript übergibt die Nachricht an Rspamd und trainiert sie als Ham
<syntaxhighlight lang="bash" copy line>
#!/bin/sh
exec /usr/bin/rspamc -h 10.0.0.8:11334 learn_ham
</syntaxhighlight>

Die Pipe-Skripte müssen für Dovecot ausführbar sein
<syntaxhighlight lang="bash" highlight="1-2" copy line>
chmod 0755 /etc/dovecot/sieve/rspamd-learn-spam.sh /etc/dovecot/sieve/rspamd-learn-ham.sh
chmod +x /etc/dovecot/sieve/rspamd-learn-spam.sh /etc/dovecot/sieve/rspamd-learn-ham.sh
</syntaxhighlight>

Die Sieve-Skripte werden kompiliert, damit Dovecot sie direkt verwenden kann
<syntaxhighlight lang="bash" highlight="1-2" copy line>
sievec /etc/dovecot/sieve/report-spam.sieve
sievec /etc/dovecot/sieve/report-ham.sieve
</syntaxhighlight>

Abschließend wird die Dovecot-Konfiguration geprüft und der Dienst neu geladen
<syntaxhighlight lang="bash" highlight="1-2" copy line>
dovecot -n
systemctl reload dovecot
</syntaxhighlight>

== Ordnernamen ==
* Der Ordnername ''Junk'' muss dem tatsächlichen IMAP-Ordnernamen entsprechen
** Mögliche abweichende Namen sind z. B. ''Spam''
* Bei abweichendem Ordnernamen müssen beide Dovecot-Blöcke angepasst werden
** Zusätzlich muss die Ausschlussliste im Ham-Skript angepasst werden

; Beispiel mit ''Spam''
<syntaxhighlight lang="console" copy line>
mailbox Spam {
sieve_script report-spam {
type = before
cause = copy
path = /etc/dovecot/sieve/report-spam.sieve
}
}

imapsieve_from Spam {
sieve_script report-ham {
type = before
cause = copy
path = /etc/dovecot/sieve/report-ham.sieve
}
}
</syntaxhighlight>

== Sicherheit ==
* Die Pipe-Skripte werden durch Dovecot ausgeführt und müssen daher kontrolliert verwaltet werden
** ''/etc/dovecot/sieve'' darf nicht durch Mailbenutzer beschreibbar sein
* Der Rspamd-Controller sollte nur aus vertrauenswürdigen Netzen erreichbar sein
* Bei Verwendung eines Passworts sollte dieses nicht in allgemein lesbaren Dateien abgelegt werden

; Rspamd-Controller mit enable_password
* ''password'' schützt lesende Controller-Kommandos
** Wird nur ''password'' gesetzt, kann dieses Passwort auch für privilegierte Kommandos verwendet werden
* ''enable_password'' schützt privilegierte Kommandos, z. B. Learning und Konfigurationsänderungen
** Wird zusätzlich ''enable_password'' gesetzt, sollte für IMAPSieve-Learning nur dieses Passwort verwendet werden

; Passwort-Hash erzeugen
* Der Hash wird auf dem Rspamd-Host erzeugt
* Der Parameter ''-p'' sollte nicht verwendet werden, da das Passwort sonst in der Shell-History oder Prozessliste sichtbar werden kann
<syntaxhighlight lang="bash" highlight="1" copy line>
rspamadm pw -q
</syntaxhighlight>

; /etc/rspamd/local.d/worker-controller.inc
* Der erzeugte Hash wird als ''enable_password'' eingetragen
** Optional kann zusätzlich ein separates ''password'' für lesende Zugriffe gesetzt werden
* Der Controller sollte nur auf einer internen Adresse oder localhost gebunden werden

<syntaxhighlight lang="text" copy line>
bind_socket = "10.2.2.8:11334";

password = "$2$READONLY_PASSWORD_HASH";
enable_password = "$2$ENABLE_PASSWORD_HASH";

secure_ip = ["127.0.0.1", "::1"];
</syntaxhighlight>

; Rspamd-Konfiguration prüfen
<syntaxhighlight lang="bash" highlight="1-2" copy line>
rspamadm configtest
systemctl restart rspamd
</syntaxhighlight>

; Passwortdatei für rspamc
* Die Passwortdatei wird auf dem Dovecot-Host angelegt
** Die Datei enthält den Klartext des ''enable_password''
* ''rspamc'' kann das Passwort über ''-P'' direkt aus dieser Datei lesen
** Dadurch erscheint das Passwort nicht als Kommandozeilenargument in der Prozessliste

<syntaxhighlight lang="bash" highlight="1-3" copy line>
printf '%s\n' 'ENABLE_PASSWORD_KLARTEXT' > /etc/dovecot/sieve/rspamd-controller.pass
chmod 0640 /etc/dovecot/sieve/rspamd-controller.pass
chown root:vmail /etc/dovecot/sieve/rspamd-controller.pass
</syntaxhighlight>

; /etc/dovecot/sieve/rspamd-learn-spam.sh
<syntaxhighlight lang="bash" copy line>
#!/bin/sh
exec /usr/bin/rspamc -h 10.0.0.8:11334 -P /etc/dovecot/sieve/rspamd-controller.pass learn_spam
</syntaxhighlight>

; /etc/dovecot/sieve/rspamd-learn-ham.sh
<syntaxhighlight lang="bash" copy line>
#!/bin/sh
exec /usr/bin/rspamc -h 10.0.0.8:11334 -P /etc/dovecot/sieve/rspamd-controller.pass learn_ham
</syntaxhighlight>

; Berechtigungen erneut prüfen
<syntaxhighlight lang="bash" highlight="1-4" copy line>
chown -R root:root /etc/dovecot/sieve
chown root:vmail /etc/dovecot/sieve/rspamd-controller.pass
chmod 0755 /etc/dovecot/sieve
chmod 0640 /etc/dovecot/sieve/rspamd-controller.pass
</syntaxhighlight>

; Zugriff testen
<syntaxhighlight lang="bash" highlight="1" copy line>
rspamc -h 10.0.0.8:11334 -P /etc/dovecot/sieve/rspamd-controller.pass stat
</syntaxhighlight>

== Test ==
; Konfiguration prüfen
* Die geladene Dovecot-Konfiguration muss die IMAPSieve- und Extprograms-Optionen enthalten

<syntaxhighlight lang="bash" highlight="1" copy line>
doveconf -n | grep -E 'imap_sieve|sieve_imapsieve|sieve_extprograms|sieve_pipe_bin_dir'
</syntaxhighlight>

; Rspamd-Verbindung prüfen
* Der Dovecot-Host muss den Rspamd-Controller erreichen können
<syntaxhighlight lang="bash" highlight="1" copy line>
rspamc -h <published_ip>:11334 stat
</syntaxhighlight>

; Logs beobachten
* Während des Tests sollten Dovecot- und Rspamd-Logs beobachtet werden

<syntaxhighlight lang="bash" highlight="1-2" copy line>
journalctl -u dovecot -u rspamd -f
tail -f /var/log/roundcube/error.log /var/log/roundcube/error.log.1
</syntaxhighlight>

{| class="wikitable options big"
! Testfall
! Aktion
! Erwartung
|-
| Spam
| Nachricht nach ''Junk'' kopieren
| ''learn_spam'' wird ausgeführt
|-
| Ham
| Nachricht aus ''Junk'' nach ''INBOX'' kopieren
| ''learn_ham'' wird ausgeführt
|-
| Trash
| Nachricht aus ''Junk'' nach ''Trash'' kopieren
| Kein Ham-Learning
|-
| Wiederholung
| Dieselbe Nachricht erneut lernen
| Rspamd kann ''already learned'' melden
|}

== Fehleranalyse ==
{| class="wikitable options big"
! Symptom
! Mögliche Ursache
! Prüfung
|-
| Kein Learning beim Verschieben
| IMAPSieve-Plugin nicht geladen
| ''doveconf -n'' prüfen
|-
| Kein Learning beim Verschieben nach Spam
| Ordnername stimmt nicht mit ''Junk'' überein
| IMAP-Ordnernamen prüfen
|-
| ''Permission denied''
| Pipe-Skript nicht ausführbar oder falsche Rechte
| Rechte unter ''/etc/dovecot/sieve'' prüfen
|-
| ''rspamc: connection refused''
| Rspamd-Controller nicht erreichbar
| Host, Port und Firewall prüfen. Socket in der Konfiguration prüfen
|-
| ''authentication failed''
| Controller-Zugriff nicht erlaubt
| ''secure_ip'' oder ''enable_password'' prüfen
|-
| ''already learned''
| Nachricht wurde bereits trainiert
| Kein Fehler, erneutes Lernen wurde übersprungen
|-
| ''contains less tokens than required''
| Nachricht ist für Bayes-Learning zu kurz
| ''min_tokens'' prüfen
|-
| Bayes-Symbol erscheint nicht im Scan-Ergebnis
| Zu wenige gelernte Spam- oder Ham-Nachrichten
| ''min_learns'' prüfen
|}

== Bayes ==
; Bayes Hinweise
Sehr kurze Nachrichten werden von Rspamd nicht für Bayes-Learning verwendet
* Der Standardwert ''min_tokens = 11'' bedeutet, dass mindestens 11 statistische Tokens vorhanden sein müssen
** Bei zu kurzen Nachrichten erscheint im Log sinngemäß eine Meldung wie:

<syntaxhighlight lang="console">
contains less tokens than required: 9 < 11
</syntaxhighlight>

Bayes wirkt nicht unmittelbar nach den ersten gelernten Nachrichten
* Der Standardwert ''min_learns = 200'' bedeutet, dass für Spam und Ham jeweils genügend gelernte Nachrichten vorhanden sein müssen, bevor die Bayes-Klassifizierung aktiv in die Bewertung einfließt

Rspamd speichert dafür gelernte IDs bzw. Signaturen im Cache und kann dann eine Meldung wie ''already learned'' zurückgeben.

{| class="wikitable options big"
! Parameter
! Standardwert
! Bedeutung
|-
| min_tokens
| ''11''
| Mindestanzahl statistischer Tokens, damit eine Nachricht für Bayes verarbeitet wird
|-
| min_learns
| ''200''
| Mindestanzahl gelernter Nachrichten pro Klasse, bevor Bayes für die Klassifizierung verwendet wird
|-
| cache_prefix
| ''learned_ids''
| Prefix für gespeicherte IDs bereits gelernter Nachrichten
|}

; Variablen anzeigen
Die aktuell wirksamen Rspamd-Parameter können über ''rspamadm configdump'' geprüft werden
<syntaxhighlight lang="bash" highlight="1" copy line>
rspamadm configdump
</syntaxhighlight>

Die Standardkonfiguration befindet sich in ''/etc/rspamd/statistic.conf''
* Diese Datei sollte nicht direkt angepasst werden, da sie zur Paketkonfiguration gehört

; Eigene Werte setzen
Eigene Bayes-Parameter werden üblicherweise in ''/etc/rspamd/local.d/classifier-bayes.conf'' gesetzt
* Die Datei ergänzt oder überschreibt die Standardwerte aus der Rspamd-Konfiguration

; /etc/rspamd/local.d/classifier-bayes.conf
<syntaxhighlight lang="console" copy line>
min_tokens = 11;
min_learns = 200;
cache_prefix = "learned_ids";
</syntaxhighlight>

Nach der Änderung wird die Rspamd-Konfiguration geprüft
<syntaxhighlight lang="bash" highlight="1" copy line>
rspamadm configtest
</syntaxhighlight>

Anschließend wird Rspamd neu gestartet, damit die geänderten Werte aktiv werden
<syntaxhighlight lang="bash" highlight="1" copy line>
systemctl restart rspamd
</syntaxhighlight>

[[Kategorie:Dovecot/Spam]]

Rspamd

2026-07-03T13:18:56Z

DanielZorin:

<noinclude>

'''{{BASEPAGENAME}}''' - Beschreibung
</noinclude>

== Beschreibung ==

== Installation ==
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>

== Aufruf ==
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>

=== Optionen ===
{| class="wikitable sortable options gnu big"
|-
! Unix !! GNU !! Parameter !! Beschreibung
|-
| || || ||
|-
|}

=== Parameter ===
=== Umgebungsvariablen ===
=== Exit-Status ===
{| class="wikitable options col1center big"
|-
! Wert !! Beschreibung
|-
| 0 || Erfolg
|-
| >0 || Fehler
|}

== Anwendung ==
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>


<syntaxhighlight lang="bash" highlight="" line>
</syntaxhighlight>

=== Problembehebung ===

== Rspamd-Konfiguration mit ISPConfig ==
Wenn Rspamd durch ISPConfig eingerichtet wurde, sollte die Konfiguration in zwei Ebenen erfolgen:

* benutzer-, mailbox- und domainbezogene Richtlinien über ISPConfig
* systemweite Rspamd-Anpassungen unter
/etc/rspamd/local.d/

=== Funktionsweise ===
Rspamd analysiert die Nachricht, berechnet einen Score und liefert daraus eine Action. Die spätere Zustellung in ''INBOX'' oder ''Junk'' erfolgt durch Dovecot/Sieve.

{| class="wikitable options big"
! Schritt
! Komponente
! Aufgabe
|-
| 1
| Postfix
| SMTP-Annahme der Nachricht
|-
| 2
| Rspamd
| Analyse, Score-Berechnung und Action-Auswahl
|-
| 3
| Postfix/Rspamd-Milter
| Ablehnen, Greylisting oder Hinzufügen von Spam-Headern
|-
| 4
| Dovecot/Sieve
| Zustellung in ''INBOX'' oder Verschieben nach ''Junk''
|}

* Für das Ziel Spam annehmen und nach ''Junk'' verschieben ist daher nicht nur der Rspamd-Score relevant
* Entscheidend ist auch, dass Rspamd Spam-Header setzt und die Mailbox so konfiguriert ist, dass Sieve diese Nachrichten nach ''Junk'' verschiebt

=== Benutzerbezogene Richtlinien ===
Die Spamfilter-Richtlinien werden in ISPConfig unter '''Email > Spamfilter > Policy''' verwaltet.

{| class="wikitable options big"
! Parameter
! Bedeutung
|-
| Spam tag level / add header
| Score, ab dem eine Nachricht als Spam markiert wird
|-
| Reject level
| Score, ab dem eine Nachricht abgelehnt wird
|-
| Greylisting level
| Score, ab dem Greylisting angewendet wird
|}

=== Systemweite Rspamd-Konfiguration ===

Systemweite Anpassungen sollten unter ''/etc/rspamd/local.d/'' abgelegt werden.

* Die Dateien ''/etc/rspamd/rspamd.conf'' sowie Dateien unter ''/etc/rspamd/modules.d/'' sollten nicht direkt angepasst werden.
* Lokale Konfigurationen unter ''local.d'' werden mit den Standardwerten zusammengeführt und bleiben bei Paket-Updates besser wartbar.

Globale Action-Schwellenwerte werden über folgende Datei gesetzt:

<syntaxhighlight lang="bash" highlight="1" copy line>
nano /etc/rspamd/local.d/actions.conf
</syntaxhighlight>

Beispiel für eine weiche Konfiguration ohne reguläre scorebasierte Ablehnung:

<syntaxhighlight lang="ini" highlight="" copy line>
reject = 100;
add_header = 6;
greylist = 4;
</syntaxhighlight>

=== Basisprüfung ===

{| class="wikitable options big"
! Befehl
! Zweck
|-
| systemctl status rspamd redis-server
| Status von Rspamd und Redis prüfen
|-
| rspamadm configtest
| Rspamd-Konfiguration auf Syntaxfehler prüfen
|-
| rspamadm configdump actions
| Aktive Action-Schwellenwerte anzeigen
|-
| rspamc stat
| Verbindung zu Rspamd prüfen und Statistik anzeigen
|}

<syntaxhighlight lang="bash" highlight="" copy line>
systemctl status rspamd redis-server
rspamadm configtest
rspamadm configdump actions
rspamc stat
</syntaxhighlight>

* Nach Änderungen an der Rspamd-Konfiguration:
<syntaxhighlight lang="bash" highlight="" copy line>
rspamadm configtest
systemctl reload rspamd
</syntaxhighlight>

=== Dateien ===
{| class="wikitable options big"
|-
! Datei !! Beschreibung
|-
| ||
|-
| ||
|}

<noinclude>


== Anhang ==
=== Siehe auch ===
<div style="column-count:2">
<categorytree hideroot=on mode="pages">rspamd</categorytree>
</div>
----
{{Special:PrefixIndex/rspamd/}}

=== Dokumentation ===


=== Links ===
==== Projekt ====
==== Weblinks ====

{{DEFAULTSORT:rspamd}}
{{DISPLAYTITLE:rspamd}}

[[Kategorie:rspamd]]

</noinclude>

Rspamd

2026-07-03T12:43:58Z

DanielZorin:

<noinclude>

'''{{BASEPAGENAME}}''' - Beschreibung
</noinclude>

== Beschreibung ==

== Installation ==
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>

== Aufruf ==
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>

=== Optionen ===
{| class="wikitable sortable options gnu big"
|-
! Unix !! GNU !! Parameter !! Beschreibung
|-
| || || ||
|-
|}

=== Parameter ===
=== Umgebungsvariablen ===
=== Exit-Status ===
{| class="wikitable options col1center big"
|-
! Wert !! Beschreibung
|-
| 0 || Erfolg
|-
| >0 || Fehler
|}

== Anwendung ==
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>


<syntaxhighlight lang="bash" highlight="" line>
</syntaxhighlight>

=== Problembehebung ===

== Rspamd-Konfiguration mit ISPConfig ==
Wenn Rspamd durch ISPConfig eingerichtet wurde, sollte die Konfiguration in zwei Ebenen erfolgen:

* benutzer-, mailbox- und domainbezogene Richtlinien über ISPConfig
* systemweite Rspamd-Anpassungen unter
/etc/rspamd/local.d/

=== Benutzerbezogene Richtlinien ===
Die Spamfilter-Richtlinien werden in ISPConfig unter '''Email > Spamfilter > Policy''' verwaltet.

{| class="wikitable options big"
! Parameter
! Bedeutung
|-
| Spam tag level / add header
| Score, ab dem eine Nachricht als Spam markiert wird
|-
| Reject level
| Score, ab dem eine Nachricht abgelehnt wird
|-
| Greylisting level
| Score, ab dem Greylisting angewendet wird
|}

=== Systemweite Rspamd-Konfiguration ===

Systemweite Anpassungen sollten unter ''/etc/rspamd/local.d/'' abgelegt werden.

* Die Dateien ''/etc/rspamd/rspamd.conf'' sowie Dateien unter ''/etc/rspamd/modules.d/'' sollten nicht direkt angepasst werden.
* Lokale Konfigurationen unter ''local.d'' werden mit den Standardwerten zusammengeführt und bleiben bei Paket-Updates besser wartbar.

Globale Action-Schwellenwerte werden über folgende Datei gesetzt:

<syntaxhighlight lang="bash" highlight="1" copy line>
nano /etc/rspamd/local.d/actions.conf
</syntaxhighlight>

Beispiel für eine weiche Konfiguration ohne reguläre scorebasierte Ablehnung:

<syntaxhighlight lang="ini" highlight="" copy line>
reject = 100;
add_header = 6;
greylist = 4;
</syntaxhighlight>

=== Basisprüfung ===

{| class="wikitable options big"
! Befehl
! Zweck
|-
| systemctl status rspamd redis-server
| Status von Rspamd und Redis prüfen
|-
| rspamadm configtest
| Rspamd-Konfiguration auf Syntaxfehler prüfen
|-
| rspamadm configdump actions
| Aktive Action-Schwellenwerte anzeigen
|-
| rspamc stat
| Verbindung zu Rspamd prüfen und Statistik anzeigen
|}

<syntaxhighlight lang="bash" highlight="" copy line>
systemctl status rspamd redis-server
rspamadm configtest
rspamadm configdump actions
rspamc stat
</syntaxhighlight>

* Nach Änderungen an der Rspamd-Konfiguration:
<syntaxhighlight lang="bash" highlight="" copy line>
rspamadm configtest
systemctl reload rspamd
</syntaxhighlight>

=== Dateien ===
{| class="wikitable options big"
|-
! Datei !! Beschreibung
|-
| ||
|-
| ||
|}

<noinclude>


== Anhang ==
=== Siehe auch ===
<div style="column-count:2">
<categorytree hideroot=on mode="pages">rspamd</categorytree>
</div>
----
{{Special:PrefixIndex/rspamd/}}

=== Dokumentation ===


=== Links ===
==== Projekt ====
==== Weblinks ====

{{DEFAULTSORT:rspamd}}
{{DISPLAYTITLE:rspamd}}

[[Kategorie:rspamd]]

</noinclude>

Linux/SELinux/04/05 Systemstart

2026-03-30T00:29:15Z

DanielZorin:

'''Linux/SELinux/04/05 Ändern der SELinux-Modi beim Systemstart'''

=== Ändern der SELinux-Modi beim Systemstart ===
Beim Systemstart können Kernel-Parameter das SELinux-Verhalten direkt während des Bootvorgangs beeinflussen.

* Diese Parameter überschreiben die übliche SELinux-Konfiguration für den jeweiligen Start.
* Sie sind vor allem für Fehlersuche, Relabeling und Notfallszenarien relevant.
* Für dauerhafte Änderungen über die Konfigurationsdatei siehe [[Linux/SELinux/04/04 Dauerhafte Änderungen|Dauerhafte Änderungen]].

{| class="wikitable options big"
! Parameter
! Wirkung
! Typischer Einsatz
|-
| ''enforcing=0''
| Start im permissiven Modus
| Fehlersuche und sicherer Start vor einem Relabeling
|-
| ''selinux=0''
| Der Kernel lädt keine SELinux-Infrastruktur
| Ausnahmefall bei schweren Startproblemen
|-
| ''autorelabel=1''
| Erzwingt ein Relabeling beim nächsten Start
| Reparatur fehlerhafter oder unvollständiger Dateilabels
|}

=== ''enforcing=0'' ===
Der Parameter ''enforcing=0'' startet das System im permissiven Modus.

<syntaxhighlight lang="text" copy line highlight="1">
enforcing=0
</syntaxhighlight>

* SELinux bleibt geladen, erzwingt die Policy jedoch nicht.
* Zugriffe werden nicht blockiert, mögliche Ablehnungen werden aber weiterhin protokolliert.
* Dieser Modus ist für die Fehlersuche besser geeignet als eine vollständige Deaktivierung.
* Neue Labels werden weiterhin korrekt erzeugt.
* Die entstehenden AVC-Meldungen können sich vom Enforcing-Modus unterscheiden, weil Prozesse nach einer protokollierten Ablehnung weiterlaufen können.

=== ''selinux=0'' ===
Der Parameter ''selinux=0'' deaktiviert SELinux bereits im Kernel.

<syntaxhighlight lang="text" copy line highlight="1">
selinux=0
</syntaxhighlight>

* Der Kernel lädt keinen Teil der SELinux-Infrastruktur.
* Dieser Parameter ist kein regulärer Weg zur Fehlersuche.
* Für Debugging sollte nach Möglichkeit ''enforcing=0'' verwendet werden.
* Wird später wieder mit aktiviertem SELinux gestartet, ist in der Regel ein Relabeling erforderlich.

; Hinweis
: Beim Start mit ''selinux=0'' wird ''/.autorelabel'' vorbereitet, damit das System beim nächsten Start mit aktiviertem SELinux neu gekennzeichnet werden kann.

=== ''autorelabel=1'' ===
Der Parameter ''autorelabel=1'' erzwingt ein Relabeling beim Start.

<syntaxhighlight lang="text" copy line highlight="1">
autorelabel=1
</syntaxhighlight>

Dies entspricht funktional dem folgenden Ablauf:

<syntaxhighlight lang="bash" copy line highlight="">
touch /.autorelabel
reboot
</syntaxhighlight>

* Wenn viele Objekte falsch oder gar nicht gelabelt sind, sollte der Start zusätzlich permissiv erfolgen.
* Dafür kann ''autorelabel=1'' mit ''enforcing=0'' kombiniert werden.

=== Relabeling vorbereiten ===
Auf Debian und RHEL kann ein Relabeling auch aus dem laufenden System für den nächsten Start vorgemerkt werden.

1.  Relabeling für den nächsten Start markieren:
<syntaxhighlight lang="bash" copy line highlight="1">
fixfiles -F onboot
</syntaxhighlight>
2.  System neu starten:
<syntaxhighlight lang="bash" copy line highlight="1">
reboot
</syntaxhighlight>
3.  Falls das System zuvor ohne SELinux betrieben wurde oder viele Labels fehlen, zusätzlich permissiv starten:
<syntaxhighlight lang="text" copy line highlight="1">
enforcing=0
</syntaxhighlight>

* ''fixfiles -F onboot'' legt die Markierung für das Relabeling des nächsten Starts an.
* Laut Debian-Dokumentation wird ''/.autorelabel'' beim automatischen Relabeling mit ''fixfiles -F restore'' ausgewertet.

=== Unterschiede zwischen Debian und RHEL ===
* Die Kernel-Parameter ''enforcing=0'', ''selinux=0'' und ''autorelabel=1'' sind distributionsunabhängig.
* RHEL dokumentiert diese Parameter direkt im SELinux-Handbuch.
* Debian dokumentiert die zugehörige Relabeling-Mechanik vor allem über ''fixfiles(8)'' und ''selinux_config(5)''.
* Die konkrete Eintragung in die Bootloader-Konfiguration ist distributions- und Bootloader-abhängig und wird hier nicht behandelt.

=== Hinweise ===
* Boot-Parameter wirken nur bei Starts, bei denen sie tatsächlich übergeben werden.
* Bleibt ein Parameter dauerhaft in der Bootloader-Konfiguration eingetragen, gilt er bei jedem weiteren Start.
* Für den normalen Betrieb sollte SELinux nicht über ''selinux=0'', sondern nur in begründeten Ausnahmefällen vollständig deaktiviert werden.

{{Navigation|Linux/SELinux/04/04 Dauerhafte Änderungen|Linux/SELinux/04/06 Booleane}}

== Weblinks ==
Red Hat Documentation:
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/changing-selinux-states-and-modes
Debian Manpages:
* https://manpages.debian.org/testing/policycoreutils/fixfiles.8.en.html
* https://manpages.debian.org/testing/policycoreutils/selinux_config.5.en.html

[[Kategorie:Linux/SELinux/04]]

Linux/SELinux/04/03 Hauptkonfigurationsdatei

2026-03-29T23:42:50Z

DanielZorin:

=== Hauptkonfigurationsdatei ===
; ''/etc/selinux/config''
* Auf Debian und RHEL ist ''/etc/selinux/config'' die zentrale SELinux-Konfigurationsdatei.
* Die Datei steuert den dauerhaften SELinux-Status und den Namen der zu ladenden SELinux-Policy.
* Änderungen in dieser Datei werden in der Regel erst nach einem Neustart wirksam.
* Temporäre Laufzeitwechsel zwischen ''enforcing'' und ''permissive'' erfolgen mit ''setenforce''.

=== Beispielkonfiguration ===
<syntaxhighlight lang="ini" copy line highlight="">
SELINUX=enforcing
SELINUXTYPE=targeted
</syntaxhighlight>

; SELINUX=
Die Option '''SELINUX''' flegt fest, ob SELinux deaktiviert oder aktiviert ist und in welchem Modus es läuft.

{| class="wikitable options big"
! Wert
! Wirkung
! Hinweis
|-
| ''enforcing''
| Die SELinux-Policy wird durchgesetzt. Zugriffe werden auf Grundlage der Policy-Regeln erlaubt oder verweigert. Verweigerungen werden protokolliert.
| Geeigneter Modus für produktive Systeme.
|-
| ''permissive''
| Die SELinux-Policy bleibt geladen, wird aber nicht durchgesetzt. Zugriffe werden nicht blockiert, mögliche Verweigerungen jedoch protokolliert.
| Geeignet für Fehlersuche, Policy-Analyse und die schrittweise Aktivierung von SELinux.
|-
| ''disabled''
| Es wird keine SELinux-Policy geladen. SELinux schützt das System in diesem Zustand nicht, und AVC-Meldungen werden nicht protokolliert.
| In aktueller Debian- und RHEL-Dokumentation wird dieser Eintrag als veraltete Methode zum dauerhaften Deaktivieren beschrieben. Für eine vollständige Deaktivierung wird ''selinux=0'' als Kernel-Parameter verwendet.
|}

Praktisches Beispiel für einen temporären Wechsel in den Permissive-Modus:

<syntaxhighlight lang="bash" copy line highlight="1">
setenforce 0
</syntaxhighlight>

* Die Änderung durch ''setenforce'' gilt nur bis zum nächsten Neustart.

; SELINUXTYPE=
Die Option '''SELINUXTYPE''' legt die zu verwendende SELinux-Policy fest.

{| class="wikitable options big"
! Wert
! Bedeutung
! Hinweis
|-
| ''targeted''
| Standard-Policy mit gezielter Einschränkung ausgewählter Dienste und Domänen.
| Auf RHEL ist ''targeted'' die übliche Standard-Policy. Auf Debian ist der Wert gültig, wenn die entsprechende Policy installiert ist.
|-
| ''mls''
| Multi-Level-Security-Policy mit zusätzlicher Trennung über Sicherheitsstufen.
| Spezialfall für MLS-Umgebungen.
|-
| ''policy_name''
| Generischer Policy-Name.
| Debian dokumentiert ''SELINUXTYPE'' allgemein als Namen der installierten Policy unter ''/etc/selinux/{SELINUXTYPE}/''.
|}

* Eine Änderung von ''SELINUXTYPE'' erfordert einen Neustart und kann zusätzlich ein Relabeling des Dateisystems notwendig machen.
* Die zugehörige Policy muss installiert sein, bevor der Wert in ''SELINUXTYPE'' verwendet wird.

=== Aktuelle Konfiguration prüfen ===
Die laufende Konfiguration und die in der Datei hinterlegten Werte lassen sich direkt prüfen:

<syntaxhighlight lang="bash" copy line highlight="">
cat /etc/selinux/config
getenforce
sestatus
</syntaxhighlight>

* ''getenforce'' zeigt den aktuellen Modus: ''Enforcing'', ''Permissive'' oder ''Disabled''.
* ''sestatus'' zeigt zusätzlich unter anderem die geladene Policy und den Modus aus der Konfigurationsdatei.

=== Hinweise zur Änderung ===
* Für dauerhafte Änderungen muss ''/etc/selinux/config'' angepasst und das System neu gestartet werden.
* Soll SELinux auf einem System aktiviert werden, auf dem es zuvor deaktiviert war, ist ''permissive'' der sichere Zwischenschritt.
* RHEL-Dokumentation konzentriert sich in der Grundkonfiguration meist auf ''SELINUX'' und ''SELINUXTYPE''.
* Debian-Manpages dokumentieren zusätzlich optionale Einträge wie ''AUTORELABEL='' und ''REQUIRESEUSERS=''.

{{Navigation|Linux/SELinux/04/02 Protokolldateien|Linux/SELinux/04/04 Dauerhafte Änderungen}}

== Weblinks ==
Red Hat Documentation:
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/changing-selinux-states-and-modes
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-main_configuration_file
Debian Manpages:
* https://manpages.debian.org/testing/policycoreutils/selinux_config.5.en.html
* https://manpages.debian.org/testing/selinux-utils/selinux.8.en.html
* https://manpages.debian.org/testing/selinux-utils/getenforce.8.en.html

[[Kategorie:Linux/SELinux/04]]

Linux/SELinux/04/02 Protokolldateien

2026-03-29T23:41:37Z

DanielZorin:

'''Linux/SELinux/04/02 Protokolldateien'''

=== Welche Protokolldatei wird verwendet ===
SELinux-Ablehnungen werden primär über das Linux-Audit-Subsystem protokolliert. Wenn der ''auditd''-Daemon läuft, werden rohe AVC-Meldungen standardmäßig in ''/var/log/audit/audit.log'' geschrieben. Für die Analyse ist diese Datei die wichtigste Quelle.

Zusätzlich können interpretierte Hinweise im Systemprotokoll erscheinen, zum Beispiel über ''setroubleshoot''. Diese Meldungen erleichtern die Einordnung, ersetzen aber nicht die rohe AVC-Meldung.

{| class="wikitable options big"
! Quelle
! Inhalt
! Zweck
|-
| ''/var/log/audit/audit.log''
| rohe Audit- und AVC-Meldungen
| erste Quelle für Analyse und Korrelation
|-
| Systemjournal
| interpretierte Meldungen, z. B. von ''setroubleshoot''
| schnelle Einordnung und Verweis auf ''sealert''
|}

* SELinux prüft Zugriffe erst nach den klassischen Dateirechten. Wird ein Zugriff bereits dort verweigert, entsteht keine SELinux-Ablehnung.

=== Beispiel einer AVC-Meldung ===
Eine AVC-Meldung kann beispielsweise wie folgt aussehen:

<syntaxhighlight lang="text" copy line highlight="">
type=AVC msg=audit(1710000000.123:321): avc: denied { getattr } for pid=1234 comm="httpd" path="/var/www/html/file1" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:samba_share_t:s0 tclass=file
</syntaxhighlight>

Die wichtigsten Bestandteile:

{| class="wikitable options big"
! Feld
! Bedeutung
|-
| ''{ getattr }''
| verweigerte Operation
|-
| ''comm="httpd"''
| aufgerufener Prozess
|-
| ''path="/var/www/html/file1"''
| betroffenes Zielobjekt
|-
| ''scontext=...:httpd_t:s0''
| SELinux-Kontext des Prozesses
|-
| ''tcontext=...:samba_share_t:s0''
| SELinux-Kontext des Zielobjekts
|-
| ''tclass=file''
| Objektklasse
|}

=== Vollständige SELinux-Meldungen ===
Für die gezielte Auswertung der Audit-Einträge eignet sich ''ausearch'':

<syntaxhighlight lang="bash" copy line highlight="">
ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
ausearch -m AVC -i -ts recent
</syntaxhighlight>

Ist ''setroubleshoot'' installiert, können zusätzliche Hinweise mit ''sealert'' angezeigt werden. Enthält eine Meldung eine lokale ID, lässt sie sich direkt auflösen:

<syntaxhighlight lang="bash" copy line highlight="1">
sealert -l <ID>
</syntaxhighlight>

Interpretierte Meldungen von ''setroubleshoot'' lassen sich im Systemjournal anzeigen:

<syntaxhighlight lang="bash" copy line highlight="1">
journalctl -t setroubleshoot
</syntaxhighlight>

=== Wenn keine Meldungen erscheinen ===
Erscheinen keine AVC-Meldungen, sollten zuerst die üblichen Fehlerquellen geprüft werden:

* Läuft ''auditd'' nicht, werden keine rohen Audit-Einträge in ''/var/log/audit/audit.log'' geschrieben.
* Ohne Treffer in ''ausearch'' sollte der blockierte Zugriff erneut ausgeführt und danach erneut gesucht werden.
* Ist ''auditd'' nicht aktiv, können einzelne SELinux-Meldungen noch im Kernel-Puffer sichtbar sein.

Praktische Prüfung:

<syntaxhighlight lang="bash" copy line highlight="">
systemctl status auditd.service
dmesg | grep -i -e type=1300 -e type=1400
</syntaxhighlight>

Für eine dauerhafte Protokollierung kann ''auditd'' aktiviert werden:

<syntaxhighlight lang="bash" copy line highlight="">
systemctl enable --now auditd.service
systemctl is-enabled auditd.service
</syntaxhighlight>

Werden Ablehnungen durch ''dontaudit''-Regeln unterdrückt, lässt sich die Protokollierung kurzfristig erweitern:

<syntaxhighlight lang="bash" copy line highlight="">
semodule -DB
# blockierten Zugriff erneut ausführen
ausearch -m AVC -i -ts recent
semodule -B
</syntaxhighlight>

{{Navigation|Linux/SELinux/04 Arbeiten mit SELinux|Linux/SELinux/04/03 Hauptkonfigurationsdatei}}

== Weblinks ==
Red Hat Documentation:
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-which_log_file_is_used
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-sealert_messages
Debian Manpages:
* https://manpages.debian.org/testing/auditd/auditd.8.en.html

[[Kategorie:Linux/SELinux/04]]

Linux/SELinux/04/03 Hauptkonfigurationsdatei

2026-03-29T23:41:31Z

DanielZorin:

=== Hauptkonfigurationsdatei ===
; ''/etc/selinux/config''
* Auf Debian und RHEL ist ''/etc/selinux/config'' die zentrale SELinux-Konfigurationsdatei.
* Die Datei steuert den dauerhaften SELinux-Status und den Namen der zu ladenden SELinux-Policy.
* Änderungen in dieser Datei werden in der Regel erst nach einem Neustart wirksam.
* Temporäre Laufzeitwechsel zwischen ''enforcing'' und ''permissive'' erfolgen mit ''setenforce''.

=== Beispielkonfiguration ===
<syntaxhighlight lang="ini" copy line highlight="">
SELINUX=enforcing
SELINUXTYPE=targeted
</syntaxhighlight>

; SELINUX=
Die Option <nowiki>[[SELINUX]]</nowiki> legt fest, ob SELinux deaktiviert oder aktiviert ist und in welchem Modus es läuft.

{| class="wikitable options big"
! Wert
! Wirkung
! Hinweis
|-
| ''enforcing''
| Die SELinux-Policy wird durchgesetzt. Zugriffe werden auf Grundlage der Policy-Regeln erlaubt oder verweigert. Verweigerungen werden protokolliert.
| Geeigneter Modus für produktive Systeme.
|-
| ''permissive''
| Die SELinux-Policy bleibt geladen, wird aber nicht durchgesetzt. Zugriffe werden nicht blockiert, mögliche Verweigerungen jedoch protokolliert.
| Geeignet für Fehlersuche, Policy-Analyse und die schrittweise Aktivierung von SELinux.
|-
| ''disabled''
| Es wird keine SELinux-Policy geladen. SELinux schützt das System in diesem Zustand nicht, und AVC-Meldungen werden nicht protokolliert.
| In aktueller Debian- und RHEL-Dokumentation wird dieser Eintrag als veraltete Methode zum dauerhaften Deaktivieren beschrieben. Für eine vollständige Deaktivierung wird ''selinux=0'' als Kernel-Parameter verwendet.
|}

Praktisches Beispiel für einen temporären Wechsel in den Permissive-Modus:

<syntaxhighlight lang="bash" copy line highlight="1">
setenforce 0
</syntaxhighlight>

* Die Änderung durch ''setenforce'' gilt nur bis zum nächsten Neustart.

; SELINUXTYPE=
Die Option '''SELINUXTYPE''' legt die zu verwendende SELinux-Policy fest.

{| class="wikitable options big"
! Wert
! Bedeutung
! Hinweis
|-
| ''targeted''
| Standard-Policy mit gezielter Einschränkung ausgewählter Dienste und Domänen.
| Auf RHEL ist ''targeted'' die übliche Standard-Policy. Auf Debian ist der Wert gültig, wenn die entsprechende Policy installiert ist.
|-
| ''mls''
| Multi-Level-Security-Policy mit zusätzlicher Trennung über Sicherheitsstufen.
| Spezialfall für MLS-Umgebungen.
|-
| ''policy_name''
| Generischer Policy-Name.
| Debian dokumentiert ''SELINUXTYPE'' allgemein als Namen der installierten Policy unter ''/etc/selinux/{SELINUXTYPE}/''.
|}

* Eine Änderung von ''SELINUXTYPE'' erfordert einen Neustart und kann zusätzlich ein Relabeling des Dateisystems notwendig machen.
* Die zugehörige Policy muss installiert sein, bevor der Wert in ''SELINUXTYPE'' verwendet wird.

=== Aktuelle Konfiguration prüfen ===
Die laufende Konfiguration und die in der Datei hinterlegten Werte lassen sich direkt prüfen:

<syntaxhighlight lang="bash" copy line highlight="">
cat /etc/selinux/config
getenforce
sestatus
</syntaxhighlight>

* ''getenforce'' zeigt den aktuellen Modus: ''Enforcing'', ''Permissive'' oder ''Disabled''.
* ''sestatus'' zeigt zusätzlich unter anderem die geladene Policy und den Modus aus der Konfigurationsdatei.

=== Hinweise zur Änderung ===
* Für dauerhafte Änderungen muss ''/etc/selinux/config'' angepasst und das System neu gestartet werden.
* Soll SELinux auf einem System aktiviert werden, auf dem es zuvor deaktiviert war, ist ''permissive'' der sichere Zwischenschritt.
* RHEL-Dokumentation konzentriert sich in der Grundkonfiguration meist auf ''SELINUX'' und ''SELINUXTYPE''.
* Debian-Manpages dokumentieren zusätzlich optionale Einträge wie ''AUTORELABEL='' und ''REQUIRESEUSERS=''.

{{Navigation|Linux/SELinux/04/02 Protokolldateien|Linux/SELinux/04/04 Dauerhafte Änderungen}}

== Weblinks ==
Red Hat Documentation:
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/changing-selinux-states-and-modes
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-main_configuration_file
Debian Manpages:
* https://manpages.debian.org/testing/policycoreutils/selinux_config.5.en.html
* https://manpages.debian.org/testing/selinux-utils/selinux.8.en.html
* https://manpages.debian.org/testing/selinux-utils/getenforce.8.en.html

[[Kategorie:Linux/SELinux/04]]

Linux/SELinux/04/02 Protokolldateien

2026-03-29T23:26:00Z

DanielZorin:

'''Linux/SELinux/04/02 Protokolldateien'''

=== Welche Protokolldatei wird verwendet ===
SELinux-Ablehnungen werden primär über das Linux-Audit-Subsystem protokolliert. Wenn der ''auditd''-Daemon läuft, werden rohe AVC-Meldungen standardmäßig in ''/var/log/audit/audit.log'' geschrieben. Für die Analyse ist diese Datei die wichtigste Quelle.

Zusätzlich können interpretierte Hinweise im Systemprotokoll erscheinen, zum Beispiel über ''setroubleshoot''. Diese Meldungen erleichtern die Einordnung, ersetzen aber nicht die rohe AVC-Meldung.

{| class="wikitable options big"
! Quelle
! Inhalt
! Zweck
|-
| ''/var/log/audit/audit.log''
| rohe Audit- und AVC-Meldungen
| erste Quelle für Analyse und Korrelation
|-
| Systemjournal
| interpretierte Meldungen, z. B. von ''setroubleshoot''
| schnelle Einordnung und Verweis auf ''sealert''
|}

* SELinux prüft Zugriffe erst nach den klassischen Dateirechten. Wird ein Zugriff bereits dort verweigert, entsteht keine SELinux-Ablehnung.

=== Beispiel einer AVC-Meldung ===
Eine AVC-Meldung kann beispielsweise wie folgt aussehen:

<syntaxhighlight lang="text" copy line highlight="">
type=AVC msg=audit(1710000000.123:321): avc: denied { getattr } for pid=1234 comm="httpd" path="/var/www/html/file1" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:samba_share_t:s0 tclass=file
</syntaxhighlight>

Die wichtigsten Bestandteile:

{| class="wikitable options big"
! Feld
! Bedeutung
|-
| ''{ getattr }''
| verweigerte Operation
|-
| ''comm="httpd"''
| aufgerufener Prozess
|-
| ''path="/var/www/html/file1"''
| betroffenes Zielobjekt
|-
| ''scontext=...:httpd_t:s0''
| SELinux-Kontext des Prozesses
|-
| ''tcontext=...:samba_share_t:s0''
| SELinux-Kontext des Zielobjekts
|-
| ''tclass=file''
| Objektklasse
|}

=== Vollständige SELinux-Meldungen ===
Für die gezielte Auswertung der Audit-Einträge eignet sich ''ausearch'':

<syntaxhighlight lang="bash" copy line highlight="">
ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
ausearch -m AVC -i -ts recent
</syntaxhighlight>

Ist ''setroubleshoot'' installiert, können zusätzliche Hinweise mit ''sealert'' angezeigt werden. Enthält eine Meldung eine lokale ID, lässt sie sich direkt auflösen:

<syntaxhighlight lang="bash" copy line highlight="1">
sealert -l <ID>
</syntaxhighlight>

Interpretierte Meldungen von ''setroubleshoot'' lassen sich im Systemjournal anzeigen:

<syntaxhighlight lang="bash" copy line highlight="1">
journalctl -t setroubleshoot
</syntaxhighlight>

=== Wenn keine Meldungen erscheinen ===
Erscheinen keine AVC-Meldungen, sollten zuerst die üblichen Fehlerquellen geprüft werden:

* Läuft ''auditd'' nicht, werden keine rohen Audit-Einträge in ''/var/log/audit/audit.log'' geschrieben.
* Ohne Treffer in ''ausearch'' sollte der blockierte Zugriff erneut ausgeführt und danach erneut gesucht werden.
* Ist ''auditd'' nicht aktiv, können einzelne SELinux-Meldungen noch im Kernel-Puffer sichtbar sein.

Praktische Prüfung:

<syntaxhighlight lang="bash" copy line highlight="">
systemctl status auditd.service
dmesg | grep -i -e type=1300 -e type=1400
</syntaxhighlight>

Für eine dauerhafte Protokollierung kann ''auditd'' aktiviert werden:

<syntaxhighlight lang="bash" copy line highlight="">
systemctl enable --now auditd.service
systemctl is-enabled auditd.service
</syntaxhighlight>

Werden Ablehnungen durch ''dontaudit''-Regeln unterdrückt, lässt sich die Protokollierung kurzfristig erweitern:

<syntaxhighlight lang="bash" copy line highlight="">
semodule -DB
# blockierten Zugriff erneut ausführen
ausearch -m AVC -i -ts recent
semodule -B
</syntaxhighlight>

== Weblinks ==
* Red Hat Documentation: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux
* Red Hat Documentation: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-which_log_file_is_used
* Red Hat Documentation: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-sealert_messages
* Debian Manpages: https://manpages.debian.org/testing/auditd/auditd.8.en.html

{{Navigation|Linux/SELinux/04 Arbeiten mit SELinux|Linux/SELinux/04/03 Hauptkonfigurationsdatei}}

[[Kategorie:Linux/SELinux/04]]

Linux/SELinux/02 Kontext

2026-03-29T23:00:43Z

DanielZorin:

'''Linux/SELinux/02 Kontext''' - Security Context Verwaltung

== Beschreibung ==
; Kennzeichnung
Prozesse und Dateien werden mit einem Kontext gekennzeichnet

; Kontext
* SELinux-Benutzer
* Rolle
* Typ
* Sicherheitsstufe

; Ausführung von SELinux
Entscheidungen zur Zugriffskontrolle des Kontexts

SELinux bietet eine Kombination aus
* [[Rollenbasierter Zugriffskontrolle]] ([[RBAC]])
* [[Typdurchsetzung]] ([[TE]])
* [[Mehrstufiger Sicherheit]] ([[MLS]])

; Beispiele für SELinux-Kontexte
SELinux-Kontexte werden auf Prozessen, Linux-Benutzern und Dateien unter Linux-Betriebssystemen verwendet, auf denen SELinux läuft

== Kontext-Syntax ==
'''SELinuxUser:role:type:level'''

; Felder
{| class="wikitable options big"
! Bestandteil
! Beispiel
! Beschreibung
|-
| user
| <name>_u
| SELinux-Benutzer
* Dieser Teil des Kontexts beschreibt die SELinux-Identität eines Subjekts oder Objekts
|-
| role
| <name>_r
| SELinux-Rolle
* Sie wird vor allem bei Prozessen und beim Login verwendet und legt fest, welche Domänen einem Subjekt zugeordnet werden dürfen
|-
| type
| '''<name>_t'''
| SELinux-Typ – 'der wichtigste Bestandteil' im Type-Enforcement-Modell

* Der Typ wird in Zugriffsregeln ausgewertet und 'bestimmt maßgeblich, welche Zugriffe für Prozesse und Objekte erlaubt sind'
|-
| level
| s0
| SELinux-Level – die Sicherheitsstufe
* In MLS- oder MCS-Szenarien kann dieser Teil auch einen Bereich mit Kategorien enthalten
* In vielen Standardszenarien erscheint hier einfach s0
|}

== Domänenübergänge ==
Ein Prozess in einer Domäne wechselt in eine andere Domäne, indem er eine Anwendung ausführt, die den Typ entrypoint für die neue Domäne hat
* Die Berechtigung entrypoint wird in der SELinux-Richtlinie verwendet und steuert, welche Anwendungen zum Betreten einer Domäne verwendet werden können
* Das folgende Beispiel veranschaulicht einen Domänenwechsel

; Ein Beispiel für einen Domänenübergang
Ein Benutzer möchte sein Passwort ändern
* Dazu führt er das Dienstprogramm passwd aus

Die ausführbare Datei /usr/bin/passwd ist mit dem Typ '''passwd_exec_t''' gekennzeichnet. Das Dienstprogramm passwd greift auf /etc/shadow zu, das mit dem Typ '''shadow_t''' gekennzeichnet ist.

Eine SELinux-Richtlinienregel besagt, dass Prozesse, die in der '''passwd_t'''-Domäne laufen, Dateien lesen und schreiben dürfen, die mit dem Typ '''shadow_t''' gekennzeichnet sind.
Wenn ein Benutzer das Dienstprogramm passwd ausführt, wechselt der Shell-Prozess des Benutzers in die '''passwd_t'''-Domäne. Da bei SELinux die Standardaktion „Verweigern“ ist und eine Regel existiert, die Anwendungen, die in der '''passwd_t'''-Domäne laufen, den Zugriff auf Dateien mit dem Typ '''shadow_t''' erlaubt, darf die passwd-Anwendung auf /etc/shadow zugreifen und das Passwort des Benutzers aktualisieren.

== Praxis: Kontexte anzeigen und ändern ==

; SELinux-Kontext von Dateien und Verzeichnissen anzeigen
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z file1
-rwxrw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
</syntaxhighlight>

; SELinux- und Linux-Benutzer
Geben Sie den folgenden Befehl als root ein, um eine Liste der Zuordnungen zwischen SELinux- und Linux-Benutzerkonten anzuzeigen (das Paket policycoreutils-python muss installiert sein):
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage login -l
Anmeldename SELinux-Benutzer MLS/MCS-Bereich Dienst

__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
</syntaxhighlight>

; Prozesskontext
Verwenden Sie den Befehl ps -eZ, um den SELinux-Kontext für Prozesse anzuzeigen.
Anzeigen des SELinux-Kontexts für das Dienstprogramm passwd:
<syntaxhighlight lang="bash" highlight="1" copy line>
ps -eZ | grep passwd
unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 13212 pts/1 00:00:00 passwd
</syntaxhighlight>

Um die SELinux-Kontexte aller laufenden Prozesse anzuzeigen, führen Sie das Dienstprogramm ps erneut aus:
<syntaxhighlight lang="bash" highlight="1" copy line>
ps -eZ
system_u:system_r:dhcpc_t:s0 1869 ? 00:00:00 dhclient
system_u:system_r:sshd_t:s0-s0:c0.c1023 1882 ? 00:00:00 sshd
system_u:system_r:gpm_t:s0 1964 ? 00:00:00 gpm
system_u:system_r:crond_t:s0-s0:c0.c1023 1973 ? 00:00:00 crond
system_u:system_r:kerneloops_t:s0 1983 ? 00:00:05 kerneloops
system_u:system_r:crond_t:s0-s0:c0.c1023 1991 ? 00:00:00 atd
</syntaxhighlight>

Die Rolle system_r wird für Systemprozesse wie Daemons verwendet. Type Enforcement trennt dann jede Domäne.

; Benutzerkontext
Verwenden Sie den folgenden Befehl, um den SELinux-Kontext anzuzeigen, der Ihrem Linux-Benutzer zugeordnet ist:
<syntaxhighlight lang="bash" highlight="1" copy line>
id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
</syntaxhighlight>

Dieser SELinux-Kontext zeigt, dass der Linux-Benutzer dem SELinux-Benutzer unconfined_u zugeordnet ist, in der Rolle unconfined_r läuft und in der Domäne '''unconfined_t''' ausgeführt wird. s0-s0 ist ein MLS-Bereich, der in diesem Fall mit s0 identisch ist. Standardmäßig laufen Linux-Benutzer in der unconfined-Rolle.

== Context setzen mit chcon ==
* Category und Sensitivity Label setzen mit chcat
<syntaxhighlight lang="bash" highlight="1" copy line>
ps -eZ | grep httpd
system_u:system_r:httpd_t:s0 16392 ? 00:00:01 apache2
</syntaxhighlight>



<noinclude>

== Anhang ==
=== Siehe auch ===
; Unterseiten
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
----
; Inhalt der aktuellen Kategorie
<div style="column-count:2">
<categorytree hideroot=on mode="pages">Linux/SELinux</categorytree>
</div>

=== Dokumentation ===


=== Links ===
==== Projekt ====
==== Weblinks ====
# [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html-single/selinux_users_and_administrators_guide/index#chap-Security-Enhanced_Linux-SELinux_Contexts Kapitel 2. SELinux-Kontexte]



----

{{Navigation|Linux/SELinux/01 Grundlagen/Installation|Linux/SELinux/03 Default Policy}}

[[Kategorie:Linux/SELinux]]

</noinclude>

Linux/SELinux/02 Kontext

2026-03-29T23:00:19Z

DanielZorin: /* To Cut */

'''Linux/SELinux/02 Kontext''' - Security Context Verwaltung

== Beschreibung ==
; Kennzeichnung
Prozesse und Dateien werden mit einem Kontext gekennzeichnet

; Kontext
* SELinux-Benutzer
* Rolle
* Typ
* Sicherheitsstufe

; Ausführung von SELinux
Entscheidungen zur Zugriffskontrolle des Kontexts

SELinux bietet eine Kombination aus
* [[Rollenbasierter Zugriffskontrolle]] ([[RBAC]])
* [[Typdurchsetzung]] ([[TE]])
* [[Mehrstufiger Sicherheit]] ([[MLS]])

; Beispiele für SELinux-Kontexte
SELinux-Kontexte werden auf Prozessen, Linux-Benutzern und Dateien unter Linux-Betriebssystemen verwendet, auf denen SELinux läuft

== Kontext-Syntax ==
'''SELinuxUser:role:type:level'''

; Felder
{| class="wikitable options big"
! Bestandteil
! Beispiel
! Beschreibung
|-
| user
| <name>_u
| SELinux-Benutzer
* Dieser Teil des Kontexts beschreibt die SELinux-Identität eines Subjekts oder Objekts
|-
| role
| <name>_r
| SELinux-Rolle
* Sie wird vor allem bei Prozessen und beim Login verwendet und legt fest, welche Domänen einem Subjekt zugeordnet werden dürfen
|-
| type
| '''<name>_t'''
| SELinux-Typ – 'der wichtigste Bestandteil' im Type-Enforcement-Modell

* Der Typ wird in Zugriffsregeln ausgewertet und 'bestimmt maßgeblich, welche Zugriffe für Prozesse und Objekte erlaubt sind'
|-
| level
| s0
| SELinux-Level – die Sicherheitsstufe
* In MLS- oder MCS-Szenarien kann dieser Teil auch einen Bereich mit Kategorien enthalten
* In vielen Standardszenarien erscheint hier einfach s0
|}

== Domänenübergänge ==
Ein Prozess in einer Domäne wechselt in eine andere Domäne, indem er eine Anwendung ausführt, die den Typ entrypoint für die neue Domäne hat
* Die Berechtigung entrypoint wird in der SELinux-Richtlinie verwendet und steuert, welche Anwendungen zum Betreten einer Domäne verwendet werden können
* Das folgende Beispiel veranschaulicht einen Domänenwechsel

; Ein Beispiel für einen Domänenübergang
Ein Benutzer möchte sein Passwort ändern
* Dazu führt er das Dienstprogramm passwd aus

Die ausführbare Datei /usr/bin/passwd ist mit dem Typ '''passwd_exec_t''' gekennzeichnet. Das Dienstprogramm passwd greift auf /etc/shadow zu, das mit dem Typ '''shadow_t''' gekennzeichnet ist.

Eine SELinux-Richtlinienregel besagt, dass Prozesse, die in der '''passwd_t'''-Domäne laufen, Dateien lesen und schreiben dürfen, die mit dem Typ '''shadow_t''' gekennzeichnet sind.
Wenn ein Benutzer das Dienstprogramm passwd ausführt, wechselt der Shell-Prozess des Benutzers in die '''passwd_t'''-Domäne. Da bei SELinux die Standardaktion „Verweigern“ ist und eine Regel existiert, die Anwendungen, die in der '''passwd_t'''-Domäne laufen, den Zugriff auf Dateien mit dem Typ '''shadow_t''' erlaubt, darf die passwd-Anwendung auf /etc/shadow zugreifen und das Passwort des Benutzers aktualisieren.

== Praxis: Kontexte anzeigen und ändern ==

; SELinux-Kontext von Dateien und Verzeichnissen anzeigen
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z file1
-rwxrw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
</syntaxhighlight>

; SELinux- und Linux-Benutzer
Geben Sie den folgenden Befehl als root ein, um eine Liste der Zuordnungen zwischen SELinux- und Linux-Benutzerkonten anzuzeigen (das Paket policycoreutils-python muss installiert sein):
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage login -l
Anmeldename SELinux-Benutzer MLS/MCS-Bereich Dienst

__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
</syntaxhighlight>

; Prozesskontext
Verwenden Sie den Befehl ps -eZ, um den SELinux-Kontext für Prozesse anzuzeigen.
Anzeigen des SELinux-Kontexts für das Dienstprogramm passwd:
<syntaxhighlight lang="bash" highlight="1" copy line>
ps -eZ | grep passwd
unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 13212 pts/1 00:00:00 passwd
</syntaxhighlight>

Um die SELinux-Kontexte aller laufenden Prozesse anzuzeigen, führen Sie das Dienstprogramm ps erneut aus:
<syntaxhighlight lang="bash" highlight="1" copy line>
ps -eZ
system_u:system_r:dhcpc_t:s0 1869 ? 00:00:00 dhclient
system_u:system_r:sshd_t:s0-s0:c0.c1023 1882 ? 00:00:00 sshd
system_u:system_r:gpm_t:s0 1964 ? 00:00:00 gpm
system_u:system_r:crond_t:s0-s0:c0.c1023 1973 ? 00:00:00 crond
system_u:system_r:kerneloops_t:s0 1983 ? 00:00:05 kerneloops
system_u:system_r:crond_t:s0-s0:c0.c1023 1991 ? 00:00:00 atd
</syntaxhighlight>

Die Rolle system_r wird für Systemprozesse wie Daemons verwendet. Type Enforcement trennt dann jede Domäne.

; Benutzerkontext
Verwenden Sie den folgenden Befehl, um den SELinux-Kontext anzuzeigen, der Ihrem Linux-Benutzer zugeordnet ist:
<syntaxhighlight lang="bash" highlight="1" copy line>
id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
</syntaxhighlight>

Dieser SELinux-Kontext zeigt, dass der Linux-Benutzer dem SELinux-Benutzer unconfined_u zugeordnet ist, in der Rolle unconfined_r läuft und in der Domäne '''unconfined_t''' ausgeführt wird. s0-s0 ist ein MLS-Bereich, der in diesem Fall mit s0 identisch ist. Standardmäßig laufen Linux-Benutzer in der unconfined-Rolle.

== Context setzen mit chcon ==
* Category und Sensitivity Label setzen mit chcat
<syntaxhighlight lang="bash" highlight="1" copy line>
ps -eZ | grep httpd
system_u:system_r:httpd_t:s0 16392 ? 00:00:01 apache2
</syntaxhighlight>



=== Links ===
==== Projekt ====
==== Weblinks ====
# [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html-single/selinux_users_and_administrators_guide/index#chap-Security-Enhanced_Linux-SELinux_Contexts Kapitel 2. SELinux-Kontexte]



----

{{Navigation|Linux/SELinux/01 Grundlagen/Installation|Linux/SELinux/03 Default Policy}}

[[Kategorie:Linux/SELinux]]

</noinclude>

Linux/SELinux/02 Kontext

2026-03-29T22:59:12Z

DanielZorin:

'''Linux/SELinux/02 Kontext''' - Security Context Verwaltung

== Beschreibung ==
; Kennzeichnung
Prozesse und Dateien werden mit einem Kontext gekennzeichnet

; Kontext
* SELinux-Benutzer
* Rolle
* Typ
* Sicherheitsstufe

; Ausführung von SELinux
Entscheidungen zur Zugriffskontrolle des Kontexts

SELinux bietet eine Kombination aus
* [[Rollenbasierter Zugriffskontrolle]] ([[RBAC]])
* [[Typdurchsetzung]] ([[TE]])
* [[Mehrstufiger Sicherheit]] ([[MLS]])

; Beispiele für SELinux-Kontexte
SELinux-Kontexte werden auf Prozessen, Linux-Benutzern und Dateien unter Linux-Betriebssystemen verwendet, auf denen SELinux läuft

== Kontext-Syntax ==
'''SELinuxUser:role:type:level'''

; Felder
{| class="wikitable options big"
! Bestandteil
! Beispiel
! Beschreibung
|-
| user
| <name>_u
| SELinux-Benutzer
* Dieser Teil des Kontexts beschreibt die SELinux-Identität eines Subjekts oder Objekts
|-
| role
| <name>_r
| SELinux-Rolle
* Sie wird vor allem bei Prozessen und beim Login verwendet und legt fest, welche Domänen einem Subjekt zugeordnet werden dürfen
|-
| type
| '''<name>_t'''
| SELinux-Typ – 'der wichtigste Bestandteil' im Type-Enforcement-Modell

* Der Typ wird in Zugriffsregeln ausgewertet und 'bestimmt maßgeblich, welche Zugriffe für Prozesse und Objekte erlaubt sind'
|-
| level
| s0
| SELinux-Level – die Sicherheitsstufe
* In MLS- oder MCS-Szenarien kann dieser Teil auch einen Bereich mit Kategorien enthalten
* In vielen Standardszenarien erscheint hier einfach s0
|}

== Domänenübergänge ==
Ein Prozess in einer Domäne wechselt in eine andere Domäne, indem er eine Anwendung ausführt, die den Typ entrypoint für die neue Domäne hat
* Die Berechtigung entrypoint wird in der SELinux-Richtlinie verwendet und steuert, welche Anwendungen zum Betreten einer Domäne verwendet werden können
* Das folgende Beispiel veranschaulicht einen Domänenwechsel

; Ein Beispiel für einen Domänenübergang
Ein Benutzer möchte sein Passwort ändern
* Dazu führt er das Dienstprogramm passwd aus

Die ausführbare Datei /usr/bin/passwd ist mit dem Typ '''passwd_exec_t''' gekennzeichnet. Das Dienstprogramm passwd greift auf /etc/shadow zu, das mit dem Typ '''shadow_t''' gekennzeichnet ist.

Eine SELinux-Richtlinienregel besagt, dass Prozesse, die in der '''passwd_t'''-Domäne laufen, Dateien lesen und schreiben dürfen, die mit dem Typ '''shadow_t''' gekennzeichnet sind.
Wenn ein Benutzer das Dienstprogramm passwd ausführt, wechselt der Shell-Prozess des Benutzers in die '''passwd_t'''-Domäne. Da bei SELinux die Standardaktion „Verweigern“ ist und eine Regel existiert, die Anwendungen, die in der '''passwd_t'''-Domäne laufen, den Zugriff auf Dateien mit dem Typ '''shadow_t''' erlaubt, darf die passwd-Anwendung auf /etc/shadow zugreifen und das Passwort des Benutzers aktualisieren.

== Praxis: Kontexte anzeigen und ändern ==

; SELinux-Kontext von Dateien und Verzeichnissen anzeigen
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z file1
-rwxrw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
</syntaxhighlight>

; SELinux- und Linux-Benutzer
Geben Sie den folgenden Befehl als root ein, um eine Liste der Zuordnungen zwischen SELinux- und Linux-Benutzerkonten anzuzeigen (das Paket policycoreutils-python muss installiert sein):
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage login -l
Anmeldename SELinux-Benutzer MLS/MCS-Bereich Dienst

__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
</syntaxhighlight>

; Prozesskontext
Verwenden Sie den Befehl ps -eZ, um den SELinux-Kontext für Prozesse anzuzeigen.
Anzeigen des SELinux-Kontexts für das Dienstprogramm passwd:
<syntaxhighlight lang="bash" highlight="1" copy line>
ps -eZ | grep passwd
unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 13212 pts/1 00:00:00 passwd
</syntaxhighlight>

Um die SELinux-Kontexte aller laufenden Prozesse anzuzeigen, führen Sie das Dienstprogramm ps erneut aus:
<syntaxhighlight lang="bash" highlight="1" copy line>
ps -eZ
system_u:system_r:dhcpc_t:s0 1869 ? 00:00:00 dhclient
system_u:system_r:sshd_t:s0-s0:c0.c1023 1882 ? 00:00:00 sshd
system_u:system_r:gpm_t:s0 1964 ? 00:00:00 gpm
system_u:system_r:crond_t:s0-s0:c0.c1023 1973 ? 00:00:00 crond
system_u:system_r:kerneloops_t:s0 1983 ? 00:00:05 kerneloops
system_u:system_r:crond_t:s0-s0:c0.c1023 1991 ? 00:00:00 atd
</syntaxhighlight>

Die Rolle system_r wird für Systemprozesse wie Daemons verwendet. Type Enforcement trennt dann jede Domäne.

; Benutzerkontext
Verwenden Sie den folgenden Befehl, um den SELinux-Kontext anzuzeigen, der Ihrem Linux-Benutzer zugeordnet ist:
<syntaxhighlight lang="bash" highlight="1" copy line>
id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
</syntaxhighlight>

Dieser SELinux-Kontext zeigt, dass der Linux-Benutzer dem SELinux-Benutzer unconfined_u zugeordnet ist, in der Rolle unconfined_r läuft und in der Domäne '''unconfined_t''' ausgeführt wird. s0-s0 ist ein MLS-Bereich, der in diesem Fall mit s0 identisch ist. Standardmäßig laufen Linux-Benutzer in der unconfined-Rolle.

== Context setzen mit chcon ==
* Category und Sensitivity Label setzen mit chcat
<syntaxhighlight lang="bash" highlight="1" copy line>
ps -eZ | grep httpd
system_u:system_r:httpd_t:s0 16392 ? 00:00:01 apache2
</syntaxhighlight>

= To Cut =

== Benutzer ==
; SELinux-Benutzeridentität

Richtlinie bekannte Identität, die für eine bestimmte Gruppe von Rollen und für einen bestimmten MLS/MCS-Bereich autorisiert ist
* Jeder Linux-Benutzer wird mithilfe der SELinux-Richtlinie einem SELinux-Benutzer zugeordnet
* Dadurch können Linux-Benutzer die für SELinux-Benutzer geltenden Einschränkungen übernehmen
* Die zugeordnete SELinux-Benutzeridentität wird im SELinux-Kontext für Prozesse in dieser Sitzung verwendet, um zu definieren, welche Rollen und Ebenen sie betreten dürfen

Die Ausgabe kann von System zu System leicht abweichen:
* Die Spalte Login Name listet Linux-Benutzer auf
* Die Spalte SELinux User listet auf, welchem SELinux-Benutzer der Linux-Benutzer zugeordnet ist

* Bei Prozessen legt der SELinux-Benutzer fest, auf welche Rollen und Ebenen zugegriffen werden kann
* Die Spalte MLS/MCS-Bereich gibt die Ebene an, die von Multi-Level Security (MLS) und Multi-Category Security (MCS) verwendet wird
* Die Spalte Dienst bestimmt den korrekten SELinux-Kontext, in dem der Linux-Benutzer am System angemeldet sein soll

* Standardmäßig wird das Sternchen (*) verwendet, das für jeden beliebigen Dienst steht

; Rolle

; Teil von SELinux ist das Sicherheitsmodell der rollenbasierten Zugriffskontrolle (RBAC)
* Die Rolle ist ein Attribut von RBAC
* SELinux-Benutzer sind für Rollen autorisiert, und Rollen sind für Domänen autorisiert

* Die Rolle dient als Vermittler zwischen Domänen und SELinux-Benutzern
* Die Rollen, auf die zugegriffen werden kann, bestimmen, auf welche Domänen zugegriffen werden kann; letztendlich steuert dies, auf welche Objekttypen zugegriffen werden kann
* Dies trägt dazu bei, die Anfälligkeit für Angriffe zur Rechteausweitung zu verringern

; Typ
Der Typ ist ein Attribut der Typdurchsetzung
* Der Typ definiert eine Domäne für Prozesse und einen Typ für Dateien
* SELinux-Richtlinienregeln definieren, wie Typen aufeinander zugreifen können, sei es eine Domäne, die auf einen Typ zugreift, oder eine Domäne, die auf eine andere Domäne zugreift
* Zugriff ist nur erlaubt, wenn eine spezifische SELinux-Richtlinienregel existiert, die dies zulässt

; level
Die Stufe ist ein Attribut von MLS und MCS
* Ein MLS-Bereich ist ein Paar von Stufen, das als lowlevel-highlevel geschrieben wird, wenn sich die Stufen unterscheiden, oder als lowlevel, wenn die Stufen identisch sind (s0-s0 entspricht s0)

* Jede Stufe ist ein Paar aus Sensitivitätsstufe und Kategorie, wobei Kategorien optional sind
* Wenn Kategorien vorhanden sind, wird die Stufe als Sensitivitätsstufe:Kategoriengruppe geschrieben
* Wenn keine Kategorien vorhanden sind, wird sie als Sensitivitätsstufe geschrieben

; Wenn die Kategoriengruppe eine zusammenhängende Reihe ist, kann sie abgekürzt werden
* Beispielsweise entspricht c0.c3 dem Ausdruck c0,c1,c2,c3
* Die Datei /etc/selinux/targeted/setrans.conf ordnet Stufen (s0:c0) einer für Menschen lesbaren Form zu (nämlich CompanyConfidential)

* In Linux setzt die gezielte Richtlinie MCS durch, und in MCS gibt es nur eine Sensitivitätsstufe, s0

* MCS in Linux unterstützt 1024 verschiedene Kategorien: c0 bis c1023. s0-s0:c0.c1023 entspricht der Sensitivitätsstufe s0 und ist für alle Kategorien autorisiert

; MLS setzt das Bell-La-Padula-Modell für zwingenden Zugriff durch und wird in LSPP-Umgebungen (Labeled Security Protection Profile) verwendet
* Um MLS-Einschränkungen zu nutzen, installieren Sie das Paket selinux-policy-mls und konfigurieren Sie MLS als Standard-SELinux-Richtlinie

* Die mit Linux gelieferte MLS-Richtlinie lässt viele Programmdomänen außer Acht, die nicht Teil der evaluierten Konfiguration waren, weshalb MLS auf einer Desktop-Workstation unbrauchbar ist (keine Unterstützung für das X Window System); es kann jedoch eine MLS-Richtlinie aus der vorgelagerten SELinux-Referenzrichtlinie erstellt werden, die alle Programmdomänen enthält

; Weitere Informationen
zur MLS-Konfiguration finden Sie unter [[Linux/SELinux/04/13 Multi-Level Security]]

== File Context Verwaltung ==
'''SELinux/File Context''' - Verhalten bei Dateisystemen mit und ohne xattr Unterstützung

; Mount Optionen
* für SELinux (context=, defcontext=, fs,context=, rootcontext=)

ls -Z /usr/bin/passwd
-rwsr-xr-x root root system_u:object_r:passwd_exec_t:s0 /usr/bin/passwd

ls -Z /etc/shadow
-r--------
root root system_u:object_r:shadow_t:s0 /etc/shadow

* Der Typ shadow_t wird nur auf Dateien angewendet, die für eine Passwortänderung erforderlich sind
* Dazu gehören /etc/gshadow, /etc/shadow und deren Sicherungsdateien

Eine SELinux-Richtlinienregel besagt, dass für die passwd_t-Domäne die entrypoint-Berechtigung auf den Typ passwd_exec_t gesetzt ist

Dieses Beispiel ist nicht erschöpfend und dient als grundlegendes Beispiel zur Erläuterung des Domänenwechsels
* Obwohl es eine tatsächliche Regel gibt, die es Subjekten, die in der passwd_t-Domäne laufen, erlaubt, auf Objekte zuzugreifen, die mit dem Dateityp shadow_t gekennzeichnet sind, müssen andere SELinux-Richtlinienregeln erfüllt sein, bevor das Subjekt in eine neue Domäne wechseln kann

: In diesem Beispiel stellt die Typdurchsetzung Folgendes sicher
* Die passwd_t-Domäne kann nur durch die Ausführung einer Anwendung betreten werden, die mit dem Typ passwd_exec_t gekennzeichnet ist; sie darf nur aus autorisierten gemeinsam genutzten Bibliotheken, wie z. B. dem Typ lib_t, ausführen; und sie darf keine anderen Anwendungen ausführen
* Nur autorisierte Domänen, wie z. B. passwd_t, können in Dateien schreiben, die mit dem Typ shadow_t gekennzeichnet sind
* Selbst wenn andere Prozesse mit Superuser-Rechten laufen, können diese Prozesse nicht in Dateien schreiben, die mit dem Typ shadow_t gekennzeichnet sind, da sie nicht in der Domäne passwd_t laufen
* Nur autorisierte Domänen können in die passwd_t-Domäne wechseln
* Beispielsweise hat der in der sendmail_t-Domäne laufende sendmail-Prozess keinen legitimen Grund, passwd<nowiki> auszuführen; daher kann er niemals in die </nowiki>passwd_t-Domäne wechseln
* Prozesse, die in der passwd_t-Domäne laufen, können nur auf autorisierte Typen lesen und schreiben, wie z. B. Dateien, die mit den Typen etc_t oder shadow_t gekennzeichnet sind
* Dies verhindert, dass die passwd-Anwendung dazu verleitet wird, beliebige Dateien zu lesen oder zu schreiben

# Öffnen Sie ein Terminal, z. B. über Anwendungen → Systemwerkzeuge → Terminal
# Führen Sie das Dienstprogramm passwd aus

Geben Sie kein neues Passwort ein:
passwd
Passwort für Benutzer ‚'user_name‘' ändern
Passwort für ‚'user_name‘' ändern
(aktuelles) UNIX-Passwort:

Öffnen Sie einen neuen Tab oder ein weiteres Terminal und geben Sie den folgenden Befehl ein
Die Ausgabe sieht in etwa wie folgt aus:

Drücken Sie im ersten Tab/Terminal Strg+C, um das Dienstprogramm passwd abzubrechen
In diesem Beispiel wechselt der Shell-Prozess des Benutzers in die Domäne passwd_t, wenn das Dienstprogramm passwd (mit dem Typ passwd_exec_t gekennzeichnet) ausgeführt wird
* Beachten Sie, dass der Typ eine Domäne für Prozesse und einen Typ für Dateien definiert

Beachten Sie, dass es sich bei der folgenden Ausgabe um ein gekürztes Beispiel handelt, das auf Ihrem System abweichen kann:

* Die Kategorien, auf die der Benutzer Zugriff hat, werden durch <tt>c0.c1023</tt> definiert, was alle Kategorien (<tt>c0</tt> bis <tt>c1023</tt>) umfasst.

{| class="wikitable options big"
! Bestandteil
! Beispiel
! Beschreibung
|-
| user
| ''<name>_u''
| SELinux User. Dieser Teil des Kontexts beschreibt die SELinux-Identität eines Subjekts oder Objekts.
|-
| role
| ''<name>_r''
| SELinux Role. Sie wird vor allem bei Prozessen und beim Login verwendet und legt fest, welche Domänen einem Subjekt zugeordnet werden dürfen.
|-
| type
| ''<name>_t''
| SELinux Type - '''der wichtigste Bestandteil''' im Type-Enforcement-Modell. Der Typ wird in Zugriffsregeln ausgewertet und '''bestimmt maßgeblich, welche Zugriffe für Prozesse und Objekte erlaubt sind'''.
|-
| level
| ''s0''
| SELinux Level - die Sicherheitsstufe. In MLS- oder MCS-Szenarien kann dieser Teil auch einen Bereich mit Kategorien enthalten. In vielen Standardszenarien erscheint hier einfach ''s0''.
|}

<noinclude>

== Anhang ==
=== Siehe auch ===
; Unterseiten
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
----
; Inhalt der aktuellen Kategorie
<div style="column-count:2">
<categorytree hideroot=on mode="pages">Linux/SELinux</categorytree>
</div>

=== Dokumentation ===


=== Links ===
==== Projekt ====
==== Weblinks ====
# [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html-single/selinux_users_and_administrators_guide/index#chap-Security-Enhanced_Linux-SELinux_Contexts Kapitel 2. SELinux-Kontexte]



----

{{Navigation|Linux/SELinux/01 Grundlagen/Installation|Linux/SELinux/03 Default Policy}}

[[Kategorie:Linux/SELinux]]

</noinclude>

Linux/SELinux/05 SEPolicy

2026-03-29T17:31:13Z

DanielZorin:

'''Linux/SELinux/05 SEPolicy''' - Sepolicy-Suite

== Beschreibung ==
'''[[sepolicy]]''' bietet eine Reihe von Funktionen zur Abfrage der installierten SELinux-Richtlinie
* Diese Funktionen sind entweder neu oder wurden zuvor von separaten Dienstprogrammen wie '''[[sepolgen]]''' oder '''[[setrans]]''' bereitgestellt
* Mit dieser Suite können Sie Übergangsberichte, Manpages oder sogar neue Richtlinienmodule erstellen, wodurch Benutzer einen einfacheren Zugang zur SELinux-Richtlinie erhalten und diese besser verstehen können

Das Paket [[policycoreutils-devel]] stellt [[sepolicy]] bereit

Geben Sie als Root-Benutzer den folgenden Befehl ein, um [[sepolicy]] zu installieren
sudo yum install policycoreutils-devel

; Funktionen von sepolicy
Die '''sepolicy'''-Suite bietet die folgenden Funktionen, die als Befehlszeilenparameter aufgerufen werden:
{| class="wikitable options big"
!Funktion
!Beschreibung
|-
|booleans
|Abfrage der SELinux-Richtlinie zur Anzeige der Beschreibung von Booleschen Werten
|-
|communicate
|Abfrage der SELinux-Richtlinie, um zu prüfen, ob Domänen miteinander kommunizieren können
|-
|generate
|Erstellung einer Vorlage für ein SELinux-Richtlinienmodul
|-
|gui
|Grafische Benutzeroberfläche für die SELinux-Richtlinie
|-
|interface
|Auflistung der SELinux-Richtlinien-Schnittstellen
|-
|manpage
|SELinux-Manpages generieren
|-
|network
|Netzwerkinformationen der SELinux-Richtlinie abfragen
|-
|transition
|SELinux-Richtlinie abfragen und einen Prozessübergangsbericht generieren
|}

== Python-Bindings ==
; sepolicy-Python-Bindings
In früheren Linux-Versionen enthielt das setools-Paket die Dienstprogramme '''sesearch''' und '''seinfo'''
* Das Dienstprogramm '''sesearch''' dient zum Suchen von Regeln in einer SELinux-Richtlinie, während das Dienstprogramm '''seinfo''' es ermöglicht, verschiedene andere Komponenten der Richtlinie abzufragen

In Linux wurden Python-Bindings für '''sesearch''' und '''seinfo''' hinzugefügt, sodass Sie die Funktionalität dieser Dienstprogramme über die '''sepolicy'''-Suite nutzen können

; Beispiel
> python
>>> import sepolicy
>>> sepolicy.info(sepolicy.ATTRIBUTE)
Returns a dictionary of all information about SELinux Attributes
>>>sepolicy.search([sepolicy.ALLOW])
Returns a dictionary of all allow rules in the policy.

== Richtlinienmodule ==
Richtlinienmodule generieren

; sepolicy generate
In früheren Linux-Versionen wurden die Dienstprogramme '''sepolgen''' oder '''selinux-polgengui''' zum Generieren einer SELinux-Richtlinie verwendet
* Diese Tools wurden in die '''sepolicy'''-Suite integriert
* Unter Linux wird der Befehl '''sepolicy generate''' verwendet, um eine erste Vorlage für ein SELinux-Richtlinienmodul zu generieren

Im Gegensatz zu '''sepolgen''' ist es nicht erforderlich, '''sepolicy generate''' als Root-Benutzer auszuführen
* Dieses Dienstprogramm erstellt außerdem eine RPM-Spec-Datei, mit der ein RPM-Paket erstellt werden kann, das die Policy-Paketdatei (''NAME''.pp) und die Schnittstellendatei (''NAME''.if) am richtigen Ort installiert, die SELinux-Policy in den Kernel integriert und die Labeling-Einstellungen anpasst
* Das Setup-Skript installiert anschließend die SELinux-Policy und richtet das Labeling ein
* Darüber hinaus wird mit dem Befehl '''sepolicy manpage''' eine Handbuchseite basierend auf der installierten Richtlinie generiert. [7] Schließlich erstellt und kompiliert '''sepolicy generate''' die SELinux-Richtlinie und die Handbuchseite zu einem RPM-Paket, das zur Installation auf anderen Systemen bereit ist

; ''sepolicy generate'' erzeugt folgenden Dateien
{| class="wikitable options big"
| ''NAME''.te || Typ-Enforcing-Datei || Diese Datei definiert alle Typen und Regeln für eine bestimmte Domäne
|-
| ''NAME''.if || Schnittstellendatei || Diese Datei definiert den Standard-Dateikontext für das System
* Sie übernimmt die in der Datei '''NAME.te''' erstellten Dateitypen und ordnet den Typen Dateipfade zu
* Dienstprogramme wie '''restorecon''' und '''rpm''' verwenden diese Pfade, um Labels zu schreiben
|-
| ''NAME''_selinux.spec || RPM-Spezifikationsdatei || Diese Datei ist eine RPM-Spezifikationsdatei, die die SELinux-Richtlinie installiert und die Labeling-Einstellungen vornimmt
* Diese Datei installiert außerdem die Schnittstellendatei und eine Man-Seite, die die Richtlinie beschreibt
* Sie können den Befehl '''sepolicy manpage -d '''NAME''' verwenden, um die Man-Seite zu generieren
|-
| ''NAME''.sh || Hilfs-Shell-Skript || Dieses Skript hilft beim Kompilieren, Installieren und Korrigieren der Kennzeichnung auf dem System
* Es generiert außerdem eine Man-Seite basierend auf der installierten Richtlinie, kompiliert und erstellt ein RPM-Paket, das für die Installation auf anderen Systemen geeignet ist
|}

Wenn es möglich ist, ein SELinux-Richtlinienmodul zu generieren, gibt '''sepolicy generate''' alle generierten Pfade von der Quelldomäne zur Zieldomäne aus
* Weitere Informationen zu '''sepolicy generate''' finden Sie auf der Man-Seite sepolicy-generate(8)

== Domänenübergänge ==
Domänenübergänge verstehen

; sepolicy transition
Früher wurde das Dienstprogramm '''setrans''' verwendet, um zu prüfen, ob ein Übergang zwischen zwei Domänen- oder Prozesstypen möglich ist, und es gab alle Zwischentypen aus, die für den Übergang zwischen diesen Domänen oder Prozessen verwendet werden
* Unter Linux ist '''setrans''' als Teil der '''sepolicy'''-Suite verfügbar, und stattdessen wird nun der Befehl '''sepolicy transition''' verwendet

Der Befehl '''sepolicy transition''' fragt eine SELinux-Richtlinie ab und erstellt einen Prozessübergangsbericht
* Der Befehl '''sepolicy transition''' benötigt zwei Befehlszeilenargumente – eine Quelldomäne (angegeben mit der Option ‚‘-s'‚) und eine Zieldomäne (angegeben mit der Option '''-t''')
* Wenn nur die Quelldomäne angegeben wird, listet '''sepolicy transition''' alle möglichen Domänen auf, zu denen die Quelldomäne wechseln kann
* Die folgende Ausgabe enthält nicht alle Einträge

Das Zeichen '''@''' bedeutet '''ausführen''':
sepolicy transition -s httpd_t
httpd_t @ httpd_suexec_exec_t --> httpd_suexec_t
httpd_t @ mailman_cgi_exec_t --> mailman_cgi_t
httpd_t @ abrt_retrace_worker_exec_t --> abrt_retrace_worker_t
httpd_t @ dirsrvadmin_unconfined_script_exec_t --> dirsrvadmin_unconfined_script_t
httpd_t @ httpd_unconfined_script_exec_t --> httpd_unconfined_script_t

Wenn die Zieldomäne angegeben ist, untersucht '''sepolicy transition''' die SELinux-Richtlinie auf alle Übergangspfade von der Quelldomäne zur Zieldomäne und listet diese Pfade auf

Die folgende Ausgabe ist unvollständig:
sepolicy transition -s httpd_t -t system_mail_t
httpd_t @ exim_exec_t --> system_mail_t
httpd_t @ courier_exec_t --> system_mail_t
httpd_t @ sendmail_exec_t --> system_mail_t
httpd_t ... httpd_suexec_t @ sendmail_exec_t --> system_mail_t
httpd_t ... httpd_suexec_t @ exim_exec_t --> system_mail_t
httpd_t ... httpd_suexec_t @ courier_exec_t --> system_mail_t
httpd_t ... httpd_suexec_t ... httpd_mojomojo_script_t @ sendmail_exec_t --> system_mail_t

Weitere Informationen zum '''sepolicy-transition''' finden Sie in der sepolicy-transition(8)-Handbuchseite

== Manpage erstellen ==
; Erstellen von Handbuchseiten: sepolicy manpage
Der Befehl '''sepolicy manpage''' generiert Handbuchseiten auf Basis der SELinux-Richtlinie, die Prozessdomänen dokumentieren
* Dadurch ist diese Dokumentation stets auf dem neuesten Stand
* Jeder Name der automatisch generierten Handbuchseiten besteht aus dem Namen der Prozessdomäne und dem Suffix '''_selinux''', zum Beispiel '''httpd_selinux'''

Die Handbuchseiten enthalten mehrere Abschnitte, die Informationen zu verschiedenen Teilen der SELinux-Richtlinie für eingeschränkte Domänen bereitstellen:
{| class="wikitable options big"
| Entrypoints || enthält alle ausführbaren Dateien, die während eines Domänenübergangs ausgeführt werden müssen
|-
| Process Types || listet alle Prozesstypen auf, die mit demselben Präfix wie die Zieldomäne beginnen
|-
| Booleans || listet die mit der Domäne verbundenen Booleschen Werte auf
|-
| Port Types || enthält die Porttypen, die mit demselben Präfix wie die Domäne übereinstimmen, und beschreibt die diesen Porttypen zugewiesenen Standardportnummern
|-
| Managed Files || beschreibt die Typen, in die die Domäne schreiben darf, sowie die diesen Typen zugeordneten Standardpfade
|-
| File Contexts || enthält alle mit der Domäne verbundenen Dateitypen und beschreibt, wie diese Dateitypen zusammen mit der Standard-Pfadkennzeichnung auf einem System verwendet werden
|-
| Sharing Files || erläutert die Verwendung der Domänen-Freigabetypen, wie '''public_content_t'''
|}

Weitere Informationen zu '''sepolicy manpage''' finden Sie auf der sepolicy-manpage(8)-Handbuchseite

[7] Weitere Informationen zu '''sepolicy manpage''' finden Sie in Abschnitt '''[[Erstellen von Handbuchseiten]]: '''sepolicy manpage'''

= Debian =
== Arbeit mit Modulen ==
Um eine maximale Performance auf Ebene der Systemaufrufe (Syscalls) zu gewährleisten, verwendet SELinux eine ''kompilierte binäre Zugriffsmatrix''.

Der Quellcode der Policy (Type Enforcement-Dateien — ''.te'') muss eine spezielle Kompilierungs- und Build-Pipeline durchlaufen, bevor er in den Kernel geladen werden kann.

Diese Pipeline besteht aus drei wesentlichen Werkzeugen:

=== checkmodule ===
Dieses Tool nimmt eine Textdatei (''.te''), prüft deren Syntax und kompiliert sie in ein binäres Zwischenformat — ein Modul (''.mod''). In diesem Schritt stellt das Programm sicher, dass alle deklarierten Typen und Klassen tatsächlich existieren.

; Wichtige Optionen:
* ''-M'': Aktiviert die Unterstützung für MLS/MCS. Bei modernen Distributionen ist diese Option '''zwingend erforderlich''', da deren Basis-Policies Kategorien verwenden.
* ''-m'': Gibt an, dass ein ladbares Modul für eine bereits existierende Policy kompiliert wird.
* ''-o <FILE.mod>'': Legt den Namen der ausgegebenen kompilierten Datei fest.

; Beispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
checkmodule -M -m -o my_rule.mod my_rule.te
</syntaxhighlight>

=== semodule_package ===
Der SELinux-Kernel akzeptiert keine ''.mod''-Dateien direkt. Diese müssen in ein spezielles Policy-Paket — Policy Package (''.pp'') — verpackt werden. Der Packager nimmt das kompilierte Modul und fügt (falls erforderlich) Dateikontext-Regeln hinzu.

; Wichtige Optionen
* ''-m <FILE.mod>'': Gibt das binäre Eingangsmodul an.
* ''-o <FILE.pp>'': Legt den Namen des resultierenden Policy-Pakets fest.
* ''-fc <FILE.fc>'': ''(Optional)'' Fügt eine Datei mit Regeln zur Markierung des Dateisystems (File Contexts) hinzu.

; Beispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
semodule_package -o my_rule.pp -m my_rule.mod
</syntaxhighlight>

=== semodule ===
Dies ist das primäre Administrationswerkzeug zur Verwaltung der im System geladenen Module. Es integriert das fertige Paket (''.pp'') in die aktive SELinux-Datenbank und wendet die Regeln im laufenden Betrieb an, ohne dass ein Systemneustart erforderlich ist.

; Wichtige Optionen
* ''-i <FILE.pp>'': Ein neues Modul installieren oder ein bestehendes aktualisieren.
* ''-r <MODULE_NAME>'': Ein installiertes Modul aus dem System entfernen.
* ''-l'': Listet alle aktuell geladenen Module auf.
* ''-X <PRIORITY>'': Legt die Priorität des Moduls fest (standardmäßig werden benutzerdefinierte Module mit der Priorität 400 installiert).

; Beispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
semodule -i my_rule.pp
</syntaxhighlight>

{{navigation|Linux/SELinux/04/16 Miniaturansichten|Linux/SELinux/06 Benutzer}}

[[Kategorie:Linux/SELinux]]

Linux/SELinux/11 Fehlerbehebung/Lösungen

2026-03-29T17:15:25Z

DanielZorin:

'''SELinux/11 Fehlerbehebung/Lösungen'''

=== Lösungen ===
; Hilfe bei der Fehlerbehebung
* Überprüfung von Linux-Berechtigungen, die vor den SELinux-Regeln geprüft werden
* mögliche Ursachen dafür, dass SELinux den Zugriff verweigert, aber keine Verweigerungen protokolliert werden
* Handbuchseiten für Dienste, die Informationen zu Labeling und Booleschen Werten enthalten
* permissive Domänen, um einem einzelnen Prozess statt dem gesamten System permissives Verhalten zu ermöglichen
* Suchen und Anzeigen von Verweigerungsmeldungen
* Analysieren von Verweigerungen
* Erstellen benutzerdefinierter Policy-Module

=== Linux-Berechtigungen ===
Wenn der Zugriff verweigert wird, überprüfen Sie die Standard-Linux-Berechtigungen
* Wie in Kapitel 1,Einführung, erwähnt, verwenden die meisten Betriebssysteme ein Discretionary Access Control (DAC)-System zur Zugriffskontrolle, das es Benutzern ermöglicht, die Berechtigungen für Dateien zu steuern, deren Eigentümer sie sind
* SELinux-Richtlinienregeln werden nach den DAC-Regeln überprüft
* SELinux-Richtlinienregeln werden nicht angewendet, wenn DAC-Regeln den Zugriff bereits verweigert haben

Wenn der Zugriff verweigert wird und keine SELinux-Verweigerungen protokolliert werden, verwenden Sie den folgenden Befehl, um die Standard-Linux-Berechtigungen anzuzeigen:
ls -l /var/www/html/index.html
-rw-r----- 1 root root 0 2009-05-07 11:06 index.html

In diesem Beispiel gehört die Datei '''index.html''' dem Root-Benutzer und der Root-Gruppe
* Der Root-Benutzer verfügt über Lese- und Schreibrechte ('''-rw'''), und Mitglieder der Root-Gruppe haben Leserechte ('''-r-''')
* Alle anderen haben keinen Zugriff ('''---''')
* Standardmäßig erlauben solche Berechtigungen '''httpd''' nicht, diese Datei zu lesen
* Um dieses Problem zu beheben, verwenden Sie den Befehl '''chown''', um den Eigentümer und die Gruppe zu ändern
* Dieser Befehl muss als root ausgeführt werden:
sudo chown apache:apache /var/www/html/index.html

Dies setzt die Standardkonfiguration voraus, in der '''httpd''' als Linux-Apache-Benutzer läuft
* Wenn Sie '''httpd''' mit einem anderen Benutzer ausführen, ersetzen Sie '''apache:apache''' durch diesen Benutzer

Informationen zur Verwaltung von Linux-Berechtigungen finden Sie im Entwurf „Permissions“ des Fedora Documentation Project

=== Stille Zugriffsverweigerungen ===
; Mögliche Ursachen für stille Zugriffsverweigerungen
In bestimmten Situationen werden AVC-Verweigerungsmeldungen möglicherweise nicht protokolliert, wenn SELinux den Zugriff verweigert
* Anwendungen und Systembibliotheksfunktionen versuchen oft, mehr Zugriff zu erlangen, als für die Ausführung ihrer Aufgaben erforderlich ist
* Um das Prinzip der geringsten Privilegien zu wahren, ohne die Audit-Protokolle mit AVC-Verweigerungen für harmlose Anwendungsversuche zu überfluten, kann die Richtlinie AVC-Verweigerungen unterdrücken, ohne die Berechtigung zu erteilen, indem sie „dontaudit“-Regeln verwendet
* Diese Regeln sind in Standardrichtlinien üblich
* Der Nachteil von „dontaudit“ ist, dass, obwohl SELinux den Zugriff verweigert, keine Verweigerungsmeldungen protokolliert werden, was die Fehlerbehebung erschwert

Um „dontaudit“-Regeln vorübergehend zu deaktivieren, sodass alle Verweigerungen protokolliert werden, geben Sie als Root den folgenden Befehl ein:
sudo semodule -DB

Die Option '''-D''' deaktiviert die „dontaudit“-Regeln; die Option '''-B''' erstellt die Richtlinie neu
* Versuchen Sie nach dem Ausführen von '''semodule -DB''' die Anwendung auszuführen, bei der zuvor Berechtigungsprobleme auftraten, und prüfen Sie, ob SELinux-Ablehnungen – die für die Anwendung relevant sind – nun protokolliert werden
* Seien Sie vorsichtig bei der Entscheidung, welche Verweigerungen zugelassen werden sollen, da einige ignoriert und durch dontaudit-Regeln behandelt werden sollten
* Wenn Sie Zweifel haben oder Rat suchen, wenden Sie sich an andere SELinux-Benutzer und -Entwickler in einer SELinux-Mailingliste, wie fedora-selinux-list

Um die Richtlinie neu zu erstellen und '''dontaudit''' -Regeln zu aktivieren, geben Sie als Root den folgenden Befehl ein:
sudo semodule -B

Dadurch wird die Richtlinie in ihren ursprünglichen Zustand zurückversetzt
* Für eine vollständige Liste der dontaudit-Regeln führen Sie den Befehl '''sesearch --dontaudit''' aus
* Grenzen Sie die Suche mit der Option '''-sdomain''' und dem Befehl '''grep''' ein

; Beispiel
sesearch --dontaudit -s smbd_t | grep squid
dontaudit smbd_t squid_port_t : tcp_socket name_bind ;
dontaudit smbd_t squid_port_t : udp_socket name_bind ;

Siehe Abschnitt „[[Raw Audit Messages]]“ und Abschnitt „[ [sealert-Meldungen]]“ für Informationen zur Analyse von Zugriffsverweigerungen

=== Handbuchseiten für Dienste ===
Handbuchseiten für Dienste enthalten wertvolle Informationen, beispielsweise welchen Dateityp in einer bestimmten Situation zu verwenden ist, sowie boolesche Werte zur Änderung der Zugriffsrechte eines Dienstes (wie '''httpd''' beim Zugriff auf NFS-Volumes)
* Diese Informationen können in der Standard-Handbuchseite oder in der Handbuchseite enthalten sein, die mit dem Dienstprogramm '''sepolicy manpage''' automatisch aus der SELinux-Richtlinie für jede Dienstdomäne generiert werden kann
* Solche Handbuchseiten sind im Format ''''‚Dienstname_selinux''' benannt
* Solche Handbuchseiten werden auch mit dem Paket selinux-policy-doc ausgeliefert

Beispielsweise enthält die Manpage httpd_selinux(8) Informationen darüber, welcher Dateityp in einer bestimmten Situation zu verwenden ist, sowie über Booleane, die Skripte, die Freigabe von Dateien, den Zugriff auf Verzeichnisse innerhalb von Benutzer-Home-Verzeichnissen usw. ermöglichen
* Weitere Manpages mit SELinux-Informationen für Dienste sind unter anderem:
* Samba: Die Manpage samba_selinux(8) beschreibt beispielsweise, dass die Aktivierung des Booleschen Werts '''samba_enable_home_dirs''' es Samba ermöglicht, Benutzer-Home-Verzeichnisse freizugeben
* NFS: Die Manpage nfsd_selinux(8) beschreibt die SELinux-nfsd-Richtlinie, die es Benutzern ermöglicht, ihre nfsd-Prozesse so sicher wie möglich einzurichten

Die Informationen in den Handbuchseiten helfen Ihnen dabei, die richtigen Dateitypen und Booleans zu konfigurieren, um zu verhindern, dass SELinux den Zugriff verweigert

Weitere Informationen zur '''sepolicy-Handbuchseite''' finden Sie im Abschnitt „[[Generieren von Handbuchseiten]]: '''sepolicy-Handbuchseite'''”

=== Permissive Domänen ===
Wenn SELinux im permissiven Modus läuft, verweigert SELinux keinen Zugriff, aber Verweigerungen werden für Aktionen protokolliert, die im Durchsetzungsmodus verweigert worden wären
* Früher war es nicht möglich, eine einzelne Domäne permissiv zu machen (denken Sie daran: Prozesse laufen in Domänen)
* In bestimmten Situationen führte dies dazu, dass das gesamte System zur Fehlerbehebung permissiv gemacht wurde

Permissive Domains ermöglichen es einem Administrator, einen einzelnen Prozess (eine Domain) so zu konfigurieren, dass er permissiv läuft, anstatt das gesamte System permissiv zu machen
* SELinux-Prüfungen werden für permissive Domains weiterhin durchgeführt; der Kernel gewährt jedoch Zugriff und meldet eine AVC-Verweigerung für Situationen, in denen SELinux den Zugriff verweigert hätte

; Verwendungszweck
* Sie können verwendet werden, um einen einzelnen Prozess (eine Domäne) permissiv laufen zu lassen, um ein Problem zu beheben, ohne das gesamte System durch die Umstellung auf den permissiven Modus zu gefährden
* Sie ermöglichen es einem Administrator, Richtlinien für neue Anwendungen zu erstellen
* Früher wurde empfohlen, eine minimale Richtlinie zu erstellen, und anschließend den gesamten Rechner in den permissiven Modus zu versetzen, damit die Anwendung ausgeführt werden konnte, SELinux-Verweigerungen jedoch weiterhin protokolliert wurden
* Das Tool '''audit2allow''' konnte dann zur Erstellung der Richtlinie herangezogen werden
* Dies stellte das gesamte System einem Risiko aus
* Mit permissiven Domänen kann nur die Domäne in der neuen Richtlinie als permissiv markiert werden, ohne das gesamte System einem Risiko auszusetzen

==== Domäne permissiv machen ====
Um eine Domäne permissiv zu machen, führen Sie den Befehl '''semanage permissive -adomain''' aus, wobeidomain die Domäne ist, die Sie permissiv machen möchten

Geben Sie beispielsweise als Root den folgenden Befehl ein, um die Domäne '''httpd_t''' (die Domäne, in der der Apache-HTTP-Server läuft) permissiv zu machen:
sudo semanage permissive -a httpd_t

Um eine Liste der Domänen anzuzeigen, die Sie als permissiv markiert haben, führen Sie als Root den Befehl '''semodule -l | grep permissive''' aus

; Beispiel
sudo semodule -l | grep permissive
permissive_httpd_t (null)
permissivedomains (null)

Wenn Sie eine Domäne nicht mehr als permissiv festlegen möchten, führen Sie den Befehl '''semanage permissive -ddomain''' als Root aus

; Beispiel
sudo semanage permissive -d httpd_t

==== Permissiven Domänen deaktivieren ====
Das Modul '''permissivedomains.pp''' enthält alle Deklarationen für permissive Domänen, die auf dem System vorhanden sind
* Um alle permissiven Domänen zu deaktivieren, geben Sie als Root den folgenden Befehl ein:
sudo semodule -d permissivedomains

; Hinweis
: Sobald ein Richtlinienmodul über den Befehl '''semodule -d''' deaktiviert wurde, wird es nicht mehr in der Ausgabe des Befehls '''semodule -l''' angezeigt

Um alle Richtlinienmodule einschließlich der deaktivierten anzuzeigen, geben Sie als Root den folgenden Befehl ein:
sudo semodule --list-modules=full

==== Ablehnungen für permissive Domänen ====
Die '''SYSCALL''' -Meldung unterscheidet sich bei permissiven Domänen
* Im Folgenden finden Sie ein Beispiel für eine AVC-Ablehnung (und den zugehörigen Systemaufruf) vom Apache-HTTP-Server:
type=AVC msg=audit(1226882736.442:86): avc: denied { getattr } for pid=2427 comm= „httpd“ path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit (1226882736. 442:86): arch=40000003 syscall=196 success=no exit=-13 a0=b9a1e198 a1=bfc2921c a2=54dff4 a3=2008171 items=0 ppid=2425 pid=2427 auid=502 uid=48 gid=4
8 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

Standardmäßig ist die Domäne '''httpd_t''' nicht permissiv, weshalb die Aktion verweigert wird und die '''SYSCALL''' -Meldung '''success=no''' enthält
* Das Folgende ist ein Beispiel für eine AVC-Verweigerung in derselben Situation, mit dem Unterschied, dass der Befehl '''semanage permissive -a httpd_t''' ausgeführt wurde, um die Domäne '''httpd_t''' permissiv zu machen:
type=AVC msg=audit(1226882925.714:136): avc: denied { read } for pid=2512 comm="httpd" name="file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u: object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit(1226882925.714:136): arch=40000003 syscall=5 success=yes exit=11 a0=b962a1e8 a1=8000 a2=0 a3=8000 items=0 ppid=2511 pid=2512 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid =48 sgid=48 fsgid=48 tty=(none) ses=4 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

In diesem Fall wurde zwar eine AVC-Ablehnung protokolliert, der Zugriff wurde jedoch nicht verweigert, wie durch '''success=yes''' in der '''SYSCALL''' -Meldung angezeigt wird

Weitere Informationen zu permissiven Domänen finden Sie in Dan Walshs Blogeintrag „Permissive Domains“

=== Suchen und Anzeigen von Verweigerungen ===
Dieser Abschnitt setzt voraus, dass die Pakete setroubleshoot, setroubleshoot-server, dbus und audit installiert sind und dass die Daemons '''auditd''', '''rsyslogd''' und '''setroubleshootd''' laufen
* Informationen zum Starten dieser Daemons finden Sie im Abschnitt „ [[Welche Protokolldatei wird verwendet]]“ für Informationen zum Starten dieser Daemons
* Es stehen eine Reihe von Dienstprogrammen zum Suchen und Anzeigen von SELinux-AVC-Meldungen zur Verfügung, wie beispielsweise '''ausearch''', '''aureport''' und '''sealert'''

=== ausearch ===
Das audit-Paket enthält das Dienstprogramm '''ausearch''', mit dem die Protokolle des '''audit'''-Daemons nach Ereignissen anhand verschiedener Suchkriterien durchsucht werden können.[10]

Das Dienstprogramm '''ausearch''' greift auf '''/var/log/audit/audit.log''' zu und muss daher als Root-Benutzer ausgeführt werden:
{| class="wikitable options big"
|-
! | Suche nach
! | Befehl
|-
|| alle Verweigerungen
|| '''ausearch -m avc,user_avc,selinux_err,user_selinux_err'''
|-
|| Verweigerungen für den heutigen Tag
|| '''ausearch -m avc -ts today'''
|-
|| Verweigerungen der letzten 10 Minuten
|| '''ausearch -m avc -ts recent'''
|-
|}

Um nach SELinux-AVC-Meldungen für einen bestimmten Dienst zu suchen, verwenden Sie die Option '''-ccomm-name''', wobeicomm-name der Name der ausführbaren Datei ist, zum Beispiel '''httpd''' für den Apache-HTTP-Server und '''smbd''' für Samba:
sudo ausearch -m avc -c httpd
sudo ausearch -m avc -c smbd

Bei jedem '''ausearch''' Befehl wird empfohlen, entweder die Option '''--interpret''' ('''-i''') für bessere Lesbarkeit oder die Option '''--raw''' ('''-r''') für die Skriptverarbeitung zu verwenden
* Weitere Optionen für '''ausearch''' finden Sie in der Handbuchseite ausearch(8)

=== aureport ===
Das Audit-Paket enthält das Dienstprogramm '''aureport'''
* das zusammenfassende Berichte der Audit-Systemprotokolle erstellt. [11]

Das Dienstprogramm '''aureport''' greift auf '''/var/log/audit/audit.log''' zu und muss daher als Root-Benutzer ausgeführt werden
* Um eine Liste der SELinux-Ablehnungsmeldungen und deren Häufigkeit anzuzeigen, führen Sie den Befehl '''aureport -a''' aus

Nachfolgend finden Sie eine Beispielausgabe, die zwei Ablehnungen enthält:
sudo aureport -a

AVC-Bericht

======================================
# Datum Uhrzeit Befehl Subjekt Systemaufruf Klasse Berechtigung Objekt Ereignis
======================================
1. 01.05.2009 21:41:39 httpd unconfined_u:system_r: httpd_t:s0 195 file getattr system_u:object_r:samba_share_t:s0 denied 2
2. 03.05.2009 22:00:25 vsftpd unconfined_u: system_r:ftpd_t:s0 5 file read unconfined_u:object_r:cifs_t:s0 denied 4

=== sealert ===
Das Paket setroubleshoot-server stellt das Dienstprogramm '''sealert''' bereit
* das die von setroubleshoot-server übersetzten Ablehnungsmeldungen ausliest.[12]
* Ablehnungen werden IDs zugewiesen, wie in '''/var/log/messages''' zu sehen ist

; Beispiel für eine Ablehnung aus ''messages''
setroubleshoot: SELinux verhindert den Zugriff von /usr/sbin/httpd auf name_bind über den tcp_socket
Für vollständige SELinux-Meldungen führen Sie sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7

In diesem Beispiel lautet die Ablehnungs-ID '''8c123656-5dda-4e5d-8791-9e3bd03786b7'''
* Die Option '''-l''' nimmt eine ID als Argument entgegen
* Die Ausführung des Befehls '''sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7''' liefert eine detaillierte Analyse, warum SELinux den Zugriff verweigert hat, sowie eine mögliche Lösung, um den Zugriff zu ermöglichen

Wenn Sie das X Window System verwenden, die Pakete [[setroubleshoot]] und [[setroubleshoot-server]] installiert haben und die Daemons '''[[setroubleshootd]]''', '''[[dbus]]''' und '''[[auditd]]''' laufen, wird eine Warnung angezeigt, wenn der Zugriff von SELinux verweigert wird:

[[Image:Bild2.png|top|alt=„Eine AVC-Ablehnungsmeldung“]]

Ein Klick auf '''Anzeigen''' startet die '''sealert''' GUI, mit der Sie das Problem beheben können:

[[Image:Bild3.png|top]]

Alternativ können Sie den Befehl '''[[sealert]] -b''' ausführen, um die '''[[sealert]]''' GUI zu starten
* Um eine detaillierte Analyse aller Verweigerungsmeldungen anzuzeigen, führen Sie den Befehl '''sealert -l \*''' aus

=== Rohdaten der Audit-Meldungen ===
Rohdaten der Audit-Meldungen werden in '''/var/log/audit/audit.log''' protokolliert

Im Folgenden finden Sie ein Beispiel für eine AVC-Ablehnungsmeldung (und den zugehörigen Systemaufruf), die auftrat, als der Apache-HTTP-Server (der in der Domäne '''httpd_t''' läuft) versuchte, auf die Datei '''/var/www/html/file1''' (mit dem Typ '''samba_share_t''' gekennzeichnet):
type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm -0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48 gid=48 euid=48 suid=4 8 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

; { getattr }
Der Eintrag in den geschweiften Klammern gibt die verweigerte Berechtigung an
* Der Eintrag '''getattr''' zeigt an, dass der Quellprozess versucht hat, die Statusinformationen der Zieldatei zu lesen
* Dies geschieht vor dem Lesen von Dateien
* Diese Aktion wird verweigert, da die Datei, auf die zugegriffen wird, ein falsches Label hat
* Häufig vorkommende Berechtigungen sind '''getattr''', '''read''' und '''write'''

; comm="httpd"
Die ausführbare Datei, die den Prozess gestartet hat
* Der vollständige Pfad der ausführbaren Datei findet sich im Abschnitt '''exe=''' der Systemaufruf-Meldung ('''SYSCALL'''), der in diesem Fall '''exe=„/usr/sbin/httpd“''' lautet

; path="/var/www/html/file1"
Der Pfad zu dem Objekt (Ziel), auf das der Prozess zuzugreifen versuchte

; <nowiki>scontext=„‚'unconfined_u:system_r:httpd_t:s0"</nowiki>
Der SELinux-Kontext des Prozesses, der die abgelehnte Aktion versucht hat
* In diesem Fall ist es der SELinux-Kontext des Apache-HTTP-Servers, der in der Domäne '''httpd_t''' läuft

; <nowiki>tcontext="unconfined_u:object_r:samba_share_t:s0"</nowiki>
Der SELinux-Kontext des Objekts (Ziels), auf das der Prozess zugreifen wollte
* In diesem Fall ist es der SELinux-Kontext von '''file1'''
* Beachten Sie, dass der Typ '''samba_share_t''' für Prozesse, die in der '''httpd_t''' Domäne laufen, nicht zugänglich ist

In bestimmten Situationen kann der '''tcontext''' mit dem '''scontext''' übereinstimmen, beispielsweise wenn ein Prozess versucht, einen Systemdienst auszuführen, der Eigenschaften des laufenden Prozesses, wie beispielsweise die Benutzer-ID, ändert
* Außerdem kann der '''tcontext''' mit dem ''' scontext''' übereinstimmen, wenn ein Prozess versucht, mehr Ressourcen (wie Speicher) zu nutzen, als die normalen Grenzen zulassen, was zu einer Sicherheitsprüfung führt, um festzustellen, ob dieser Prozess diese Grenzen überschreiten darf

; Systemaufruf-Meldung
Aus der Systemaufruf-Meldung ('''SYSCALL''') sind zwei Punkte von Interesse:
* '''success=‚'no''': gibt an, ob die Verweigerung (AVC) durchgesetzt wurde oder nicht
**'''success=no''' bedeutet, dass der Systemaufruf nicht erfolgreich war (SELinux hat den Zugriff verweigert). '''success=yes''' bedeutet, dass der Systemaufruf erfolgreich war
** Dies ist bei permissiven Domänen oder unconfined Domänen zu beobachten, wie beispielsweise '''unconfined_service_t''' und '''kernel_t'''
* '''exe=„'''/usr/sbin/httpd''“ ''': der vollständige Pfad zu der ausführbaren Datei, die den Prozess gestartet hat; in diesem Fall ist dies '''exe=„/usr/sbin/httpd“'''

; Falscher Dateityp
Ein falscher Dateityp ist eine häufige Ursache dafür, dass SELinux den Zugriff verweigert
* Um mit der Fehlerbehebung zu beginnen, vergleichen Sie den Quellkontext ('''scontext''') mit dem Zielkontext ('''tcontext''' )
* Sollte der Prozess ('''scontext''') auf ein solches Objekt ('''tcontext''') zugreifen?
* Beispielsweise sollte der Apache-HTTP-Server ('''httpd_t''') nur auf Typen zugreifen, die in der Handbuchseite httpd_selinux(8) angegeben sind, wie '''httpd_sys_content_t''', ''' public_content_t'‚ usw., sofern nicht anders konfiguriert

=== sealert-Meldungen ===
Verweigerungen werden IDs zugewiesen, wie in '/var/log/messages''

; Beispiel
AVC-Verweigerung (protokolliert in '''messages''') die auftrat, als der Apache-HTTP-Server (der in der Domäne '''httpd_t''' läuft) versuchte, auf die Datei '''/var/www/html/file1''' (mit dem Typ '''samba_share_t''' gekennzeichnet) zuzugreifen:

hostname setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/file1 (samba_share_t). For complete SELinux messages. run sealert -l 32eee32b-21ca-4846-a22f-0ba050206786

; Vollständige Meldung anzuzeigen
sealert -l 32eee32b-21ca-4846-a22f-0ba050206786

Dieser Befehl funktioniert nur auf dem lokalen Rechner und zeigt dieselben Informationen an wie die '''sealert''' GUI:
sealert -l 32eee32b-21ca-4846-a22f-0ba050206786
SELinux verhindert, dass httpd mit getattr auf die Datei /var/www/html/file1 zugreift

***** Das Plugin restorecon (92,2 % Zuverlässigkeit) schlägt vor ************************
Wenn Sie das Label korrigieren möchten

Das Standard-Label für /var/www/html/file1 sollte httpd_sys_content_t lauten
Dann können Sie restorecon ausführen
Führen Sie
sudo /sbin/restorecon -v /var/www/html/file1

***** Das Plugin public_content (Vertrauenswürdigkeit 7,83) schlägt vor ********************
Wenn Sie file1 als öffentlichen Inhalt behandeln möchten, dann müssen Sie die Label von file1 in public_content_t oder public_content_rw_t ändern
Führen Sie Folgendes aus
sudo semanage fcontext -a -t public_content_t ‚/var/www/html/file1‘

sudo restorecon -v ‚/var/www/html/file1‘
***** Das Plugin catchall (Vertrauenswürdigkeit 1,41) schlägt vor **************************

Wenn Sie der Meinung sind, dass httpd standardmäßig getattr-Zugriff auf die Datei file1 erhalten sollte
* Dann sollten Sie dies als Fehler melden

Sie können ein lokales Richtlinienmodul erstellen, um diesen Zugriff zuzulassen
Erlauben

Sie diesen Zugriff vorerst durch Ausführung von:
sudo ausearch -c ‚httpd‘ --raw | audit2allow -M my-httpd
sudo semodule -i my-httpd.pp

Zusätzliche Informationen:
Quellkontext system_u:system_r:httpd_t:s0

Zielkontext unconfined_u:object_r:samba_share_t:s0
Zielobjekte /var/www/html/file1 [ Datei ]
Quelle httpd
Quellpfad httpd
Port <Unbekannt>
Host hostname.redhat.com
Quell-RPM-Pakete
Ziel-RPM-Pakete
Richtlinien-RPM selinux-policy-3.13.1-166.el7.noarch

Selinux aktiviert True
Richtlinientyp targeted
Durchsetzungsmodus Enforcing
Hostname hostname.redhat.com
Plattform Linux hostname.redhat.com
3.10.0-693.el7.x86_64 #1 SMP Do, 6
* Juli 19:56:57
EDT 2017 x86_64 x86_64

Anzahl der Warnmeldungen 2
Erstmals gesehen 20.07.2017 02:52:11 EDT
Zuletzt gesehen 20.07.2017 02:52:11 EDT
Lokale ID 32eee32b-21ca-4846-a22f-0ba050206786

Rohdaten der Audit-Meldungen
type=AVC msg=audit(1500533531.140:295): avc: abgelehnt { getattr } für pid=24934 comm="httpd" path="/var/www/html/file1" dev="vda1" ino=31457414 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

Hash: httpd,httpd_t,samba_share_t,file,getattr

==== Zusammenfassung ====

Eine kurze Zusammenfassung der abgelehnten Aktion
* Dies entspricht der Ablehnung in '''/var/log/messages'''
* In diesem Beispiel wurde dem Prozess '''httpd''' der Zugriff auf eine Datei ('''file1''') verweigert, die mit dem Typ '''samba_share_t''' gekennzeichnet ist
>Detaillierte Beschreibung

==== Ausführliche Beschreibung ====
* In diesem Beispiel ist '''file1''' mit dem Typ '''samba_share_t''' gekennzeichnet
* Dieser Typ wird für Dateien und Verzeichnisse verwendet, die Sie über Samba exportieren möchten
* Die Beschreibung schlägt vor, den Typ in einen Typ zu ändern, auf den der Apache-HTTP-Server und Samba zugreifen können, falls ein solcher Zugriff erforderlich ist

==== Zugriff gewähren ====
Ein Vorschlag, wie der Zugriff gewährt werden kann
* Dies kann das Umbenennen von Dateien, das Aktivieren eines booleschen Werts oder das Erstellen eines lokalen Richtlinienmoduls sein
* In diesem Fall lautet der Vorschlag, die Datei mit einem Typ zu kennzeichnen, auf den sowohl der Apache-HTTP-Server als auch Samba zugreifen können

==== Befehl zur Behebung des Problems ====
Ein vorgeschlagener Befehl, um den Zugriff zu gewähren und die Zugriffsverweigerung zu beheben
* In diesem Beispiel wird der Befehl angegeben, den Typ von '''file1''' in '''public_content_t''' zu ändern, der sowohl für den Apache-HTTP-Server als auch für Samba zugänglich ist

==== Zusätzliche Informationen ====
Informationen, die in Fehlerberichten nützlich sind, wie der Name und die Version des Richtlinienpakets ('''selinux-policy-3.13.1-166.el7.noarch'''), die jedoch möglicherweise nicht zur Klärung der Ursache für die Zugriffsverweigerung beitragen

==== Rohdaten der Audit-Meldungen ====
Die Rohdaten der Audit-Meldungen aus '''/var/log/audit/audit.log''', die mit der Verweigerung in Verbindung stehen
* Informationen zu den einzelnen Elementen der AVC-Verweigerung finden Sie in Abschnitt 11.3.6, „Rohdaten der Audit-Meldungen“

=== Zugriff zulassen ===
[[audit2allow]]
; Warnung
: Verwenden Sie das Beispiel in diesem Abschnitt nicht in der Produktion
:* Es dient lediglich zur Veranschaulichung der Verwendung des Dienstprogramms '''[[audit2allow]]'''

'''[[audit2allow]]''' sammelt Informationen aus den Protokollen abgelehnter Vorgänge und generiert daraus SELinux-Policy-Zulassungsregeln.

Nachdem Sie die Ablehnungsmeldungen gemäß Abschnitt „[[sealert-Meldungen]]“, analysiert haben und sofern keine Label-Änderungen oder Boolesche Werte den Zugriff erlaubt haben, verwenden Sie '''audit2allow''', um ein lokales Policy-Modul zu erstellen
* Wenn der Zugriff von SELinux verweigert wird, generiert die Ausführung von '''audit2allow''' Type-Enforcement-Regeln, die den zuvor verweigerten Zugriff erlauben

Sie sollten '''audit2allow''' nicht als erste Option zum Erstellen eines lokalen Richtlinienmoduls verwenden, wenn Sie eine SELinux-Ablehnung feststellen
* Die Fehlerbehebung sollte mit einer Überprüfung beginnen, ob ein Labeling-Problem vorliegt
* Der zweithäufigste Fall ist, dass Sie eine Prozesskonfiguration geändert und vergessen haben, SELinux darüber zu informieren
* Weitere Informationen finden Sie im Whitepaper „Die vier Hauptursachen für SELinux-Fehler“

; Verwendung von '''audit2allow''' zum Erstellen eines Policy-Moduls
1. Eine Verweigerungsmeldung und der zugehörige Systemaufruf werden in der Datei '''/var/log/audit/audit.log''' protokolliert:
type=AVC msg=audit(122627035.848:238): avc: denied { write } for pid=13349 comm="certwatch" name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir
type=SYSCALL msg=audit(1226270358.848:238): arch=40000003 syscall=39 success=no exit=-13 a0=39a2bf a1=3ff a2=3a0354 a3=94703c8 items=0 ppid=13344 pid=13349 auid=4294967295 uid=0 gid=0 euid=0 suid= 0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="certwatch" exe="/usr/bin/certwatch" subj=system_u: system_r:certwatch_t:s0 key=(null)

In diesem Beispiel wurde '''certwatch''' der Schreibzugriff auf ein Verzeichnis verweigert, das mit dem Typ '''var_t''' gekennzeichnet ist
* Analysieren Sie die Ablehnungsmeldung gemäß Abschnitt 11.3.7, „sealert-Meldungen“
* Wenn keine Label-Änderungen vorgenommen wurden oder Booleane den Zugriff erlaubt haben, verwenden Sie '''audit2allow''', um ein lokales Richtlinienmodul zu erstellen

2. Geben Sie den folgenden Befehl ein, um eine für Menschen lesbare Beschreibung zu erstellen, warum der Zugriff verweigert wurde

Das Dienstprogramm '''[[audit2allow]]''' liest die Datei '''/var/log/audit/audit.log''' und muss daher als Root-Benutzer ausgeführt werden:
sudo audit2allow -w -a
type=AVC msg=audit(1226270358.848:238): avc: verweigert { schreiben } für pid=13349 comm="certwatch" name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir
Ursache:
Fehlende Type Enforcement (TE)-Zulassungsregel

Sie können audit2allow verwenden, um ein ladbares Modul zu generieren, das diesen Zugriff erlaubt

Die Befehlszeilenoption '''-a''' bewirkt, dass alle Audit-Protokolle gelesen werden
* Die Option '''-w''' erzeugt eine für Menschen lesbare Beschreibung
* Wie gezeigt, wurde der Zugriff aufgrund einer fehlenden Type Enforcement-Regel verweigert
# Geben Sie den folgenden Befehl ein, um die Type Enforcement-Regel anzuzeigen, die den verweigerten Zugriff erlaubt:
sudo audit2allow -a
; certwatch_t
allow certwatch_t var_t:dir write;

; Wichtig
: Fehlende Type Enforcement-Regeln werden in der Regel durch Fehler in der SELinux-Richtlinie verursacht und sollten in Red Hat Bugzilla gemeldet werden
* Erstellen Sie für das Produkt '''Red 

Hat Enterprise Linux''' und wählen Sie die Komponente '''selinux-policy''' aus
* Fügen Sie die Ausgabe der Befehle '''audit2allow -w -a''' und '''audit2allow -a''' in solche Fehlerberichte ein

# Um die von '''audit2allow -a'''' angezeigte Regel zu verwenden, geben Sie als Root den folgenden Befehl ein, um ein benutzerdefiniertes Modul zu erstellen
* Die Option '''-M''' erstellt eine Type-Enforcement-Datei ('''.te''') mit dem durch '''-M''' angegebenen Namen in Ihrem aktuellen Arbeitsverzeichnis:
sudo audit2allow -a -M mycertwatch
******************** WICHTIG ********** *************
Um dieses Richtlinienpaket zu aktivieren, führen Sie Folgendes aus:

semodule -i mycertwatch.pp

# Außerdem kompiliert '''audit2allow''' die Type Enforcement-Regel in ein Richtlinienpaket ('''.pp'''):

sudo ls
mycertwatch.pp mycertwatch.te

Um das Modul zu installieren, geben Sie als Root den folgenden Befehl ein:
sudo semodule -imycertwatch.pp

; Wichtig
: Mit '''audit2allow''' erstellte Module gewähren möglicherweise mehr Zugriff als erforderlich
:* Es wird empfohlen, mit '''audit2allow''' erstellte Richtlinien zur Überprüfung an die Upstream-SELinux-Liste zu senden
:* Wenn Sie glauben, dass die Richtlinie einen Fehler enthält, melden Sie diesen bitte in Red Hat Bugzilla

Wenn Sie mehrere Ablehnungsmeldungen von verschiedenen Prozessen erhalten, aber nur eine benutzerdefinierte Richtlinie für einen einzelnen Prozess erstellen möchten, verwenden Sie das Dienstprogramm '''grep''', um die Eingabe für '''audit2allow''' einzugrenzen

Das folgende Beispiel zeigt, wie man mit '''grep''' nur Ablehnungsmeldungen im Zusammenhang mit '''certwatch''' an '''audit2allow''' sendet:
sudo grep certwatch /var/log/audit/audit.log | audit2allow -R -M mycertwatch2
******************** WICHTIG ***************** ******
Um dieses Richtlinienpaket zu aktivieren, führen Sie Folgendes aus:
semodule -i mycertwatch2.pp

== Eigene Policy-Module mit audit2allow ==

;Prinzip
Wenn Standardlösungen (wie Booleans oder Dateikontexte) nicht ausreichen, analysiert ''audit2allow'' die Audit-Protokolle und generiert automatisch Regeln, um zuvor blockierte Aktionen systemweit zuzulassen.

; Installation
Unter Debian ist das Tool Teil der Python-Utilities für SELinux:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo apt install policycoreutils-python-utils
</syntaxhighlight>

; Analyse
Prüfen Sie zunächst die menschenlesbare Erklärung der Blockaden, um die Ursache zu verstehen:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo audit2allow -w -a
</syntaxhighlight>

; Modul generieren
Filtern Sie die Logs gezielt nach dem betroffenen Dienst (z. B. ''nginx''), um keine unerwünschten Rechte freizugeben, und erstellen Sie das Modul:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo grep mein_prozess /var/log/audit/audit.log | audit2allow -M mein_modul
</syntaxhighlight>

Dies erzeugt eine Quellcode-Datei (''.te'') und das kompilierte Policy-Paket (''.pp'')

; Modul aktivieren
Laden Sie das kompilierte Paket abschließend in den Kernel:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semodule -i mein_modul.pp
</syntaxhighlight>

; Initiale Einrichtung
Nach einer frischen SELinux-Installation und der Deinstallation von AppArmor wird das System oft mit unklaren AVC-Meldungen geflutet. Um das System initial wieder nutzbar zu machen, können Sie alle bisherigen Blockaden pauschal erfassen:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo grep "AVC" /var/log/audit/audit.log | audit2allow -M my_custom_policy
</syntaxhighlight>

Laden Sie auch dieses Modul anschließend mit
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semodule -i my_custom_policy.pp
</syntaxhighlight>
;Hinweis
Diese "Holzhammer-Methode" eignet sich nur für die allererste Stabilisierung des Systems. Im späteren Betrieb sollten Sie Ausnahmen immer strikt nach Diensten getrennt erstellen.

[[Kategorie:Linux/SELinux/11]]

Linux/SELinux/11 Fehlerbehebung

2026-03-29T17:15:07Z

DanielZorin:

Linux/SELinux/04/09 Dateisysteme

2026-03-29T17:08:26Z

DanielZorin:

Linux/SELinux/04/09 Dateisysteme

2026-03-29T17:05:05Z

DanielZorin:

= Debian =
=== Mount-Optionen ===
Standardmäßig wird beim Einbinden eines Dateisystems der Sicherheitskontext für jede Datei aus dem erweiterten Attribut (xattr) der Datei gelesen. Wenn ein Dateisystem jedoch keine xattr unterstützt (wie FAT oder NFS) oder dem Datenträger nicht vertraut wird (z. B. USB-Sticks), kann der Sicherheitskontext direkt beim Mounten erzwungen oder angepasst werden.

==== context= (Globale Überschreibung) ====
Die Option ''context='' ist in zwei Hauptfällen nützlich:
* Das Dateisystem '''unterstützt keine''' xattr, sodass ein normales SELinux-Labeling darauf nicht möglich ist;
* Dem Dateisystem '''kann im Hinblick auf bereits vorhandene Attribute nicht vertraut werden''', und beim Mounten muss vorübergehend ein einheitlicher sicherer Kontext erzwungen werden (z. B. Wechselmedien).

Wenn ''context='' gesetzt ist, versucht SELinux nicht mehr, xattr vom Datenträger zu lesen. Auch die Datenbank ''file_contexts'' wird für diesen Pfad ignoriert.

; Wichtig
: Es ist nicht möglich, das Label einer einzelnen Datei innerhalb einer solchen Ressource mit ''chcon'' oder ''restorecon'' zu ändern — der Kernel gibt in diesem Fall einen Fehler zurück (''Operation not supported''). Die ursprünglichen Kontexte (falls auf der Festplatte vorhanden) bleiben erhalten und sind bei einem späteren Mounten ohne ''context='' wieder sichtbar.

; Befehlsbeispiele
Für Wechselmedien:
<syntaxhighlight lang="bash" highlight="1" copy line>
mount -o context="system_u:object_r:removable_t:s0" /dev/sdb1 /mnt/usb
</syntaxhighlight>

Für eine Netzwerkressource, die vom Webserver gelesen werden soll:
<syntaxhighlight lang="bash" highlight="1" copy line>
mount server:/export /srv/www -o context="system_u:object_r:httpd_sys_content_t:s0"
</syntaxhighlight>

==== defcontext= (Standardkontext) ====
Die Option ''defcontext='' dient einer anderen Aufgabe: Sie '''ändert den Kontext für unlabeled Dateien'''.

Sie wirkt nur dort, wo ein Objekt '''kein eigenes SELinux-Label auf dem Datenträger''' hat.
* Wenn eine Datei bereits ein Label hat, verwendet SELinux dieses.
* Wenn kein Label vorhanden ist (zum Beispiel, wenn eine Datei aus einem alten System ohne SELinux-Unterstützung kopiert wurde), wird ihr „on the fly“ der in ''defcontext='' angegebene Kontext zugewiesen. Neue Dateien erben dieses Label und speichern es physisch ab (sofern das Dateisystem xattr unterstützt).

; Befehlsbeispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
mount /dev/sdb2 /test -o defcontext="system_u:object_r:samba_share_t:s0"
</syntaxhighlight>

==== rootcontext= (Kontext des Mount-Punkts) ====
Die Option ''rootcontext='' erlaubt es, den Kontext des '''Root-Inodes''' eines Dateisystems explizit festzulegen, '''bevor es im Userspace sichtbar wird'''.
* Sie bestimmt den Kontext ausschließlich für das '''Wurzelverzeichnis''' des eingehängten Dateisystems, ohne dessen Inhalt zu beeinflussen.

Das ist nützlich, wenn das korrekte Label für das Verzeichnis selbst (zum Beispiel /mnt/backup) gesetzt werden soll, damit Dienste es betreten können, während die individuellen Labels aller enthaltenen Dateien auf dem Datenträger erhalten bleiben.
<syntaxhighlight lang="bash" highlight="1" copy line>
mount -t tmpfs none /srv/chroot -o rootcontext="system_u:object_r:tmp_t:s0"
</syntaxhighlight>

==== fscontext= (Kontext des Superblocks) ====
Weist der abstrakten Dateisysteminstanz selbst einen Kontext als Objekt zu, nicht den darin enthaltenen Dateien.

Dies ist eine Low-Level-Option. Sie wird von SELinux selbst verwendet, um zu bestimmen, ob ein bestimmter Prozess das Recht hat, Dateisysteme dieses Typs einzuhängen. In der täglichen Administration wird sie manuell nur äußerst selten verwendet.

=== Aufgabe: Verhalten von Mount-Optionen prüfen ===
Wir erstellen zwei Mount-Punkte:
<syntaxhighlight lang="bash" highlight="" copy line>
sudo mkdir -p /mnt/lab_context
sudo mkdir -p /mnt/lab_rootcontext
</syntaxhighlight>

Wir mounten tmpfs mit einem global erzwungenen Kontext (''context=''):
<syntaxhighlight lang="bash" highlight="" copy line>
sudo mount -t tmpfs none /mnt/lab_context -o context="system_u:object_r:httpd_sys_content_t:s0"
ls -Zd /mnt/lab_context
</syntaxhighlight>

Nun erstellen wir einige Objekte darin und versuchen, den Kontext manuell zu ändern:
<syntaxhighlight lang="bash" highlight="" copy line>
touch /mnt/lab_context/file1
mkdir /mnt/lab_context/dir1
chcon -t tmp_t /mnt/lab_context/file1
</syntaxhighlight>
'''Der Kernel gibt einen Fehler zurück''', da bei Verwendung des Mount-Parameters ''context='' eine Kontextänderung für einzelne Dateien blockiert wird.

Nun versuchen wir, ein anderes Dateisystem mit dem Parameter ''rootcontext='' einzuhängen:
<syntaxhighlight lang="bash" highlight="" copy line>
mount -t tmpfs none /mnt/lab_rootcontext -o rootcontext="system_u:object_r:samba_share_t:s0"
touch /mnt/lab_rootcontext/file1
mkdir /mnt/lab_rootcontext/dir1
ls -lZ1 /mnt/lab_rootcontext
</syntaxhighlight>
Wie man sehen kann, wurde der Kontext der Dateien vom Root-Verzeichnis geerbt.

Nun versuchen wir, den Kontext manuell zu ändern:
<syntaxhighlight lang="bash" highlight="" copy line>
chcon -R -t tmp_t /mnt/lab_rootcontext/*
ls -lZ1 /mnt/lab_rootcontext/
</syntaxhighlight>
'''Der Vorgang wird erfolgreich ausgeführt''', da ''rootcontext='' nur den Kontext des Wurzelverzeichnisses des eingehängten Dateisystems starr festlegt, die darin erstellten Dateien jedoch individuell anpassbar bleiben.

=== Besonderheiten bei NFS und mehrfachen Mounts ===
Standardmäßig werden NFS-Einhängungen auf der Client-Seite mit einem Standardkontext gekennzeichnet (meist ''nfs_t''). Dienste wie der Apache-HTTP-Server oder MariaDB können oft nicht auf ''nfs_t'' zugreifen, weshalb der Kontext beim Mounten überschrieben werden muss.
* ''Hinweis:'' Alternativ zum Überschreiben des Kontexts können auch SELinux-Booleans (z. B. ''httpd_use_nfs'') verwendet werden, um Diensten den Zugriff zu gestatten.

Wenn jedoch '''mehrere Mounts aus demselben NFS-Export''' durchgeführt werden und versucht wird, den SELinux-Kontext jedes Mounts durch einen jeweils anderen Kontext zu überschreiben, blockiert das System mit einem Superblock-Fehler (''"Same superblock, different security settings"'').

Um dasselbe Unterverzeichnis eines Exports mehrfach mit unterschiedlichen Kontexten einzuhängen, muss zwingend die Option '''''nosharecache''''' verwendet werden:
<syntaxhighlight lang="bash" highlight="" copy line>
sudo mount server:/export/web /local/web -o nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
sudo mount server:/export/database /local/database -o nosharecache,context="system_u:object_r:mysqld_db_t:s0"
</syntaxhighlight>

=== Kontext-Mounts dauerhaft machen (Persistenz) ===
Da Befehle wie ''mount -o context=...'' temporär sind und Systemneustarts nicht überleben, müssen die Optionen in der Datei '''/etc/fstab''' oder in einer Automounter-Zuordnung eingetragen werden, um sie persistent zu machen.

Beispiel für einen Eintrag in der ''/etc/fstab'' für eine NFS-Kontext-Einbindung:
<syntaxhighlight lang="bash" highlight="1" copy line>
server:/export /local/mount/ nfs context="system_u:object_r:httpd_sys_content_t:s0" 0 0
</syntaxhighlight>

== Wiederherstellung korrekter Labels ==
; Relabeling mit restorecon

Der Arbeitsablauf von restorecon lässt sich vereinfacht wie folgt beschreiben
# Das Werkzeug übernimmt einen Zielpfad und liest die aktive SELinux-Policy bzw. die zugehörige File-Context-Datenbasis
# Der Zielpfad wird gegen die regulären Ausdrücke aus der Policy-Datenbasis abgeglichen
# Das Werkzeug liest den tatsächlich gesetzten erweiterten Dateiattributwert (xattr) des Objekts direkt aus dem Dateisystem
# Anschließend erfolgt ein Vergleich zwischen dem laut Policy erwarteten Kontext und dem tatsächlich gesetzten Label (Attribut) des Objekts
# Falls die Prüfung rekursiv für ein Verzeichnis ausgeführt wurde, berechnet restorecon einen Hash über die dabei verwendeten regulären Ausdrücke und speichert ihn im versteckten Attribut des Verzeichnisses security.sehash
#* Beim nächsten Lauf beginnt Schritt 2 dann mit dem Vergleich dieses Hashes, um Zeit zu sparen

==== Verwendung ====
In der Praxis werden drei Betriebsarten verwendet

; Passive Prüfung ohne Änderungen
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -nv /var/www/html/index.html
</syntaxhighlight>

Die Option -n verhindert das Schreiben neuer Labels und versetzt das Werkzeug in den Prüfmodus
* Der Parameter -v zeigt Objekte an, deren Labels vom erwarteten Zustand abweichen

; Korrektur eines einzelnen Objekts
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -v /var/www/html/index.html
</syntaxhighlight>

Korrigiert den Kontext der angegebenen Datei
* Praktisch werden dabei genau die Änderungen angewendet, die im vorherigen Beispiel lediglich angezeigt wurden

; Massenhafte rekursive Korrektur eines Verzeichnisbaums
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -Rv /var
</syntaxhighlight>

Die Optionen -R und -r aktivieren den rekursiven Verzeichnisdurchlauf
* Genau dieser Modus wird typischerweise nach dem Hinzufügen neuer Regeln mit semanage fcontext oder nach einer beschädigten Teil-Relabeling-Situation verwendet

=== customizable types ===
In SELinux existiert ein Ausnahme-Mechanismus für Relabeling mit der Bezeichnung customizable types

Dabei handelt es sich um eine vordefinierte Liste von Kontexten (Typen), die vom System als manuell administrierbar betrachtet werden
* Entsprechend werden solche Dateien bei der Prüfung und beim Relabeling durch SELinux-Werkzeuge und -Mechanismen (einschließlich restorecon, .autorelabel, setfiles, fixfiles) ignoriert

Die Liste der customizable types wird aus folgender Datei gelesen
<syntaxhighlight lang="bash" highlight="1" copy line>
/etc/selinux/{SELINUXPOLICY}/contexts/customizable_types
</syntaxhighlight>

Obwohl der Mechanismus der customizable types in modernen Distributionen weiterhin existiert und funktioniert, gilt er in der Administratoren-Community heute als '''veraltender Ansatz'''
* Der Grund ist, dass die Datei lediglich Informationen darüber enthält, welche Typen ignoriert werden, nicht jedoch, welchen konkreten Dateien diese Typen zugewiesen wurden
* In einer Störungssituation kann diese Information unwiederbringlich verloren gehen
* Die File-Context-Datenbank enthält dagegen alle erforderlichen Informationen, um den gewünschten Label-Zustand im Dateisystem reproduzierbar wiederherzustellen

Um Dateien mit customizable types dennoch zwangsweise auf den vollständig erwarteten Kontext zurückzusetzen, muss restorecon mit dem Parameter -F (Force) ausgeführt werden
* In diesem Fall werden '''alle Felder des Kontexts wiederhergestellt'''
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -F -v /srv/custom_app
</syntaxhighlight>

=== Beschleunigung durch Digest-Prüfung ===
; Das Werkzeug restorecon_xattr
Beim rekursiven Relabeling mit restorecon -D durchläuft das Werkzeug den Verzeichnisbaum nicht nur und korrigiert Kontexte, sondern '''schreibt zusätzlich einen internen Digest in das xattr des Verzeichnisses'''.

; Digest wird im erweiterten Attribut ''security.sehash'' gespeichert

Die Aufgabe dieses Digests besteht darin festzuhalten, dass dieses Verzeichnis bereits gegen einen bestimmten Satz von file_contexts-Dateien geprüft wurde, die für die Zuordnung von Pfaden zu erwarteten Kontexten verwendet werden
* Beim nächsten Lauf von restorecon -D wird dieser Hash zur Prüfung herangezogen und bei Bedarf aktualisiert, falls er veraltet ist
In modernen RHEL-Versionen wird zur Berechnung dieses Werts '''der kryptographische Algorithmus SHA-256''' verwendet (in älteren Systemen kam SHA-1 zum Einsatz).
'''Red Hat/Fedora''' verwenden seit RHEL 9 bzw. Fedora 34+ beim Paket-Build einen eigenen Patch für den Quellcode
* In den Paketquellen findet sich dazu direkt eine Datei mit dem Namen 0001-Use-SHA-2-instead-of-SHA-1.patch

Debian verwendet weiterhin SHA-1
* Das ist in diesem Kontext jedoch unkritisch, da der Hash im Verzeichnis-xattr nicht für Sicherheitsfunktionen oder Verschlüsselung verwendet wird

==== restorecon_xattr ====
Für die Arbeit mit diesen internen Digest-Einträgen (Anzeigen/Bereinigen) stehen folgende Kommandos zur Verfügung
* restorecon -D (Hashes erzeugen / Dateien unter Verwendung vorhandener Hashes prüfen)
* restorecon -I (Hashes erzeugen / neu erzeugen, wobei vorhandene ignoriert werden)
* sowie das separate Werkzeug restorecon_xattr (Hashes anzeigen / löschen)

; Funktionen von restorecon_xattr
* '''Verzeichnisse anzeigen''', in denen security.sehash vorhanden ist
* '''Digest und dessen Status''' im Vergleich zum aktuellen Policy-Satz anzeigen
* '''nur veraltete Digest-Einträge löschen'''
* '''alle Digest-Einträge''' in einem angegebenen Verzeichnisbaum löschen

; Praxisbeispiel mit einigen Hashes
Start von restorecon mit dem Flag -D und rekursivem Modus -R
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -RDv /var/log
</syntaxhighlight>

Anzeige des Ergebnisses mit restorecon_xattr (zusätzlich mit -r für rekursive Ausgabe)
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon_xattr -r /var/log
</syntaxhighlight>

Zum Entfernen von Hashes, die nicht mehr zum aktuellen Policy-Satz passen, wird der Parameter -d verwendet

Das Werkzeug berechnet einen neuen Hash und entfernt den alten Hash bei Nichtübereinstimmung (neue Hashes werden dabei nicht geschrieben)
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon_xattr -d -r /var/www
</syntaxhighlight>

Vollständiges Entfernen aller Digests
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon_xattr -D -r /var/www
</syntaxhighlight>

Dabei werden alle security.sehash-Einträge aus dem Verzeichnisbaum entfernt, unabhängig davon, ob sie noch aktuell sind oder nicht
* Der nächste Lauf von restorecon -D muss die Digests anschließend vollständig neu erzeugen

Wichtig ist, dass sich der Nutzen von restorecon -D erst bei '''rekursiver Verarbeitung''' (-R / -r) entfaltet
* Nach einem erfolgreichen rekursiven Relabeling wird beim erneuten Ausführen von restorecon -D (mit denselben Parametern und demselben Policy-Satz) der gespeicherte Digest zur Beschleunigung des Verzeichnisdurchlaufs verwendet
* Das ist insbesondere bei der Prüfung großer Verzeichnisbäume oder sogar des gesamten Dateisystems ab / nützlich

Das bedeutet: '''Wenn der Parameter''' -D '''gesetzt ist''', wird für '''Verzeichnisse ohne vorhandenen Hash''' ein neuer Digest berechnet und in den Attributen gespeichert
* Falls '''für ein Verzeichnis bereits ein Hash existiert''', prüft restorecon dessen Gültigkeit, indem es ihn mit dem neu aus der File-Context-Datenbank berechneten Wert vergleicht. '''Bei Übereinstimmung wird das Verzeichnis beschleunigt verarbeitet.''' '''Bei Nichtübereinstimmung erfolgt die Prüfung des aktuellen Verzeichnisses und aller Unterverzeichnisse im normalen Modus''', also so, als wäre -D nicht gesetzt

Wird der Parameter -D nicht verwendet, nutzt restorecon den Mechanismus security.sehash bei der Prüfung überhaupt nicht

Wird restorecon -I verwendet, wird ein bereits gespeicherter Digest ignoriert
* Selbst wenn security.sehash formal übereinstimmt, vertraut restorecon diesem Eintrag nicht und '''führt im rekursiven Modus zwangsweise eine erneute vollständige Label-Prüfung durch; anschließend wird der Digest aktualisiert'''
* Voraussetzung ist, dass das Flag -n nicht gesetzt ist und während der Ausführung keine Fehler auftreten

; Anwendungsbeispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -RIv /var/log
</syntaxhighlight>

Das Verzeichnis wird rekursiv geprüft, und jeder Hash wird unabhängig davon, ob bereits ein Digest in den Attributen vorhanden ist, neu erzeugt

== Relabeling-Werkzeuge ==
; Die Werkzeuge für Relabeling lassen sich in drei Ebenen unterteilen

* setfiles
** Das grundlegende, low-level ausführbare Binärprogramm (in C geschrieben)
** Es bildet den Kernmechanismus zur Anwendung der Policy
** restorecon arbeitet auf Basis von setfiles
* restorecon
** Ein Werkzeug auf Benutzerebene, das für gezielte administrative Eingriffe vorgesehen ist
** restorecon findet, lädt und verwendet automatisch die '''aktuell aktive SELinux-Policy'''
** Das Werkzeug restorecon wird durch dieselbe ausführbare Datei implementiert wie setfiles
** Der Betriebsmodus wird über argv[0] gewählt, also über den Namen, unter dem das Programm aufgerufen wird
* fixfiles
** Dabei handelt es sich nicht um eine Binärdatei, sondern um ein Shell-Skript, das den Aufruf von setfiles und restorecon für globale Systemaufgaben automatisiert
** Es ist eine skriptbasierte Wrapper-Schicht für typische Wartungsoperationen wie check, verify, restore, relabel, onboot sowie für paketbezogene und inkrementelle Betriebsarten
** Das Werkzeug kann mit der Datenbank des Paketmanagers (RPM) arbeiten
** So kann es beispielsweise alle Dateien ermitteln, die zu einem bestimmten Paket gehören, und ausschließlich diese neu labeln
** Außerdem steuert es den Ablauf eines vollständigen System-Relabelings beim Booten

=== Betriebsarten von fixfiles ===
==== fixfiles check / fixfiles verify ====
check und verify sind Betriebsarten ohne Änderung der Labels
* Sie geben alle inkorrekten Labels aus und zeigen dabei den alten sowie den neuen Kontext an, schreiben jedoch nichts zurück
* Das ist ein praktischer administrativer Audit-Modus vor einem Relabeling oder nach Änderungen an den Regeln

; Beispiel
<syntaxhighlight lang="bash" highlight="" copy line>
chcon -R -t tmp_t /var/www
chcon -R -t shadow_t /srv
fixfiles check /var/www /srv
</syntaxhighlight>

==== fixfiles restore ====
restore stellt inkorrekte Labels wieder her

; Beispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
fixfiles restore /var/www /srv/app
</syntaxhighlight>

==== fixfiles relabel ====
relabel ist für ein vollständiges Relabeling des gesamten Dateisystems vorgesehen
* Das Werkzeug schlägt vor, den Inhalt von /tmp zu löschen
* Anschließend werden alle inkorrekten Dateilabels so korrigiert, dass sie den installierten file_contexts entsprechen

; Beispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
fixfiles relabel
</syntaxhighlight>

==== fixfiles onboot ====
onboot führt das Relabeling nicht sofort aus, sondern bereitet das System so vor, dass das Relabeling beim nächsten Systemstart erfolgt
<syntaxhighlight lang="bash" highlight="1" copy line>
fixfiles onboot
</syntaxhighlight>

=== Optionen ===
; Wichtige Optionen
{| class="wikitable options big"
|-
! Unix !! Beschreibung
|-
| -F || (Force) Setzt den Kontext auch bei Dateien mit customizable types zwangsweise zurück
|-
| -f || (force clear) Leert die temporären Verzeichnisse /tmp und /var/tmp automatisch vor Beginn der Ausführung, ohne interaktive Rückfragen
* Das ist besonders nützlich für Automatisierungsskripte
|-
| -C PREVIOUS_FILECONTEXT || (Compare) Vergleicht einen alten file_contexts-Stand mit dem aktuellen und stellt Kontexte nur dort wieder her, wo dies erforderlich ist
|-
| -N "YYYY-MM-DD HH:MM" || (Newer) Beschränkt die Verarbeitung auf Dateien, die nach dem angegebenen Zeitpunkt erstellt wurden
|-
| -B || Im Modus restore werden nur Dateien berücksichtigt, die heute verändert wurden
* Im Modus onboot schreibt derselbe Schalter das aktuelle Datum in /.autorelabel, wodurch das Relabeling beschleunigt werden kann
|-
| -M || (Mounts) Führt vor dem Relabeling Bind-Mounts für Dateisysteme aus, sodass auch Kontexte von Objekten korrekt repariert werden können, über denen etwas eingehängt ist
|-
| -T nthreads || (Threads) Konfiguriert die parallele Verarbeitung mit mehreren Threads oder deaktiviert diese bei -T 1
|-
| -l LOGPATH || (Log) Leitet die gesamte Ausgabe, also sowohl Standardausgabe als auch Fehlermeldungen, in die angegebene Logdatei statt auf den Bildschirm um
|}

== RHEL ==

=== Einbinden von Dateisystemen ===
Standardmäßig wird beim Einbinden eines Dateisystems, das erweiterte Attribute unterstützt, der Sicherheitskontext für jede Datei aus dem ‚'security.selinux‘'

erweiterten Attribut der Datei
* Dateien in Dateisystemen, die keine erweiterten Attribute unterstützen, wird ein einziger Standard-Sicherheitskontext aus der Richtlinienkonfiguration zugewiesen, basierend auf dem Dateisystemtyp

Verwenden Sie den Befehl [[mount -o context]], um vorhandene erweiterte Attribute zu überschreiben oder einen anderen Standardkontext für Dateisysteme festzulegen, die keine erweiterten Attribute unterstützen
* Dies ist nützlich, wenn Sie nicht darauf vertrauen, dass ein Dateisystem die richtigen Attribute bereitstellt, beispielsweise bei Wechselmedien, die in mehreren Systemen verwendet werden
* Der Befehl [[mount -o context]] kann auch verwendet werden, um die Kennzeichnung für Dateisysteme zu unterstützen, die keine erweiterten Attribute unterstützen, wie z. B. File Allocation Table (FAT) oder NFS-Volumes
* Der mit der Option [[context]] angegebene Kontext wird nicht auf die Festplatte geschrieben
die ursprünglichen Kontexte bleiben erhalten und sind beim Einbinden ohne [[context]] sichtbar, sofern das Dateisystem ursprünglich über erweiterte Attribute verfügte

Weitere Informationen zur Dateisystem-Kennzeichnung finden Sie in James Morris' Artikel „Filesystem Labeling in SELinux“
http://www.linuxjournal.com/article/7426

==== Kontext-Mounts ====
Um ein Dateisystem mit dem angegebenen Kontext zu mounten – wobei vorhandene Kontexte überschrieben werden, falls vorhanden – oder um einen anderen Standardkontext für ein Dateisystem festzulegen, das keine erweiterten Attribute unterstützt, verwenden Sie als Root-Benutzer den [[mount -o context=‚'SELinux_user:role:type:level‘']] beim Einhängen des gewünschten Dateisystems
* Kontextänderungen werden nicht auf die Festplatte geschrieben
* Standardmäßig werden NFS-Einhängungen auf der Client-Seite mit einem Standardkontext gekennzeichnet, der durch die Richtlinie für NFS-Volumes definiert ist
* In gängigen Richtlinien verwendet dieser Standardkontext den Typ [[nfs_t]]
* Ohne zusätzliche Mount-Optionen kann dies die Freigabe von NFS-Volumes über andere Dienste, wie den Apache-HTTP-Server, verhindern
* Das folgende Beispiel mountet ein NFS-Volume so, dass es über den Apache-HTTP-Server freigegeben werden kann
sudo mount server:/export /local/mount/point -o \ context="system_u:object_r:httpd_sys_content_t:s0"

Neu erstellte Dateien und Verzeichnisse auf diesem Dateisystem scheinen den mit [[-o context]] angegebenen SELinux-Kontext zu haben
* Da diese Änderungen jedoch nicht auf die Festplatte geschrieben werden, bleibt der mit dieser Option angegebene Kontext zwischen den Mountvorgängen nicht erhalten
* Daher muss diese Option bei jedem Mountvorgang mit demselben Kontext verwendet werden, um den erforderlichen Kontext beizubehalten
* Informationen dazu, wie man Kontext-Mounts dauerhaft macht, finden Sie im Abschnitt „Kontext-Mounts dauerhaft machen“

Die Typen-Durchsetzung ist die wichtigste Berechtigungssteuerung, die in der SELinux-Targeted-Policy verwendet wird
* In den meisten Fällen können SELinux-Benutzer und -Rollen ignoriert werden. Verwenden Sie daher beim Überschreiben des SELinux-Kontexts mit [[-o context]] den SELinux-Benutzer [[system_u]] und die Rolle [[object_r]] und konzentrieren Sie sich auf den Typ
* Wenn Sie nicht die MLS-Policy oder die Multi-Kategorie-Sicherheit verwenden, verwenden Sie die [[s0]]-Ebene

; Hinweis

Wenn ein Dateisystem mit einer [[context]]-Option eingebunden wird, sind Kontextänderungen durch Benutzer und Prozesse untersagt
* Wenn Sie beispielsweise den Befehl [[chcon]] auf einem mit einer [[context]]-Option eingebundenen Dateisystem ausführen, führt dies zu einem Fehler [[Operation not supported]]

==== Ändern des Standardkontexts ====
Wie in Abschnitt 4.8, „Die Typen file_t und default_t“ , wird auf Dateisystemen, die erweiterte Attribute unterstützen, beim Zugriff auf eine Datei, der auf der Festplatte ein SELinux-Kontext fehlt, so behandelt, als hätte sie einen Standardkontext, wie er durch die SELinux-Richtlinie definiert ist
* In gängigen Richtlinien verwendet dieser Standardkontext den Typ [[file_t]]
* Wenn ein anderer Standardkontext verwendet werden soll, mounten Sie das Dateisystem mit der Option [[defcontext]]

Das folgende Beispiel mountet ein neu erstelltes Dateisystem auf [[/
dev/sda2]] in das neu erstellte Verzeichnis [[test/]] ein
* Dabei wird davon ausgegangen, dass es in [[/etc/selinux/targeted/contexts/files/]] keine Regeln gibt, die einen Kontext für das Verzeichnis [[test/]] definieren
sudo mount /dev/sda2 /test/ -o defcontext="system_u:object_r:samba_share_t:s0"

In diesem Beispiel
* definiert die Option [[defcontext]], dass [[system_u:object_r:samba_share_t:s0]] „der Standard-Sicherheitskontext für nicht gekennzeichnete Dateien“ ist[5]
* wird das Stammverzeichnis ([[test/]]) des Dateisystems nach dem Einbinden so behandelt, als wäre es mit dem durch [[defcontext]] angegebenen Kontext gekennzeichnet (diese Kennzeichnung wird nicht auf der Festplatte gespeichert)
* Dies wirkt sich auf die Kennzeichnung von Dateien aus, die unter [[test/]] erstellt werden
neue Dateien erben den Typ [[samba_share_t]], und diese Kennzeichnungen werden auf der Festplatte gespeichert
* Dateien, die unter [[test/]] erstellt wurden, während das Dateisystem mit der Option [[defcontext]] eingebunden war, behalten ihre Kennzeichnungen

==== Einbinden eines NFS-Volumes ====
Standardmäßig werden NFS-Einbindungen auf der Client-Seite mit einem Standardkontext gekennzeichnet, der durch die Richtlinie für NFS-Volumes definiert ist
* In gängigen Richtlinien verwendet dieser Standardkontext den Typ [[nfs_t]]
* Je nach Richtlinienkonfiguration können Dienste wie der Apache-HTTP-Server und MariaDB möglicherweise keine Dateien lesen, die mit dem Typ [[nfs_t]] gekennzeichnet sind
* Dies kann verhindern, dass Dateisysteme, die mit diesem Typ gekennzeichnet sind, eingebunden und anschließend von anderen Diensten gelesen oder exportiert werden

Wenn Sie ein NFS-Volume mounten und dieses Dateisystem mit einem anderen Dienst lesen oder exportieren möchten, verwenden Sie beim Mounten die Option [[context]], um den Typ [[nfs_t]] zu überschreiben
* Verwenden Sie die folgende context-Option, um NFS-Volumes so einzuhängen, dass sie über den Apache-HTTP-Server freigegeben werden können
sudo mount server:/export /local/mount/point -o context="system_u:object_r:httpd_sys_content_t:s0"

Da diese Änderungen nicht auf die Festplatte geschrieben werden, bleibt der mit dieser Option angegebene Kontext zwischen den Einhängevorgängen nicht erhalten
* Daher muss diese Option bei jedem Einbinden mit demselben Kontext verwendet werden, um den erforderlichen Kontext beizubehalten
* Informationen dazu, wie Kontext-Mounts dauerhaft gemacht werden können, finden Sie im Abschnitt „Kontext-Mounts dauerhaft machen“

Als Alternative zum Einbinden von Dateisystemen mit [[context]]-Optionen können Boolesche Werte aktiviert werden, um Diensten den Zugriff auf Dateisysteme zu ermöglichen, die mit dem Typ [ [nfs_t]] gekennzeichnet sind
* Siehe Teil II, „Verwaltung eingeschränkter Dienste“ für Anweisungen zur Konfiguration von Booleans, um Diensten den Zugriff auf den Typ [[nfs_t]] zu ermöglichen

==== Mehrere NFS-Mounts ====
Wenn mehrere Mounts aus demselben NFS-Export durchgeführt werden und versucht wird, den SELinux-Kontext jedes Mounts durch einen anderen Kontext zu überschreiben, führen nachfolgende Mount-Befehle zu Fehlern
* Im folgenden Beispiel verfügt der NFS-Server über einen einzigen Export, [[export/]], der zwei Unterverzeichnisse enthält: [ [web/]] und [[database/]]
* Die folgenden Befehle versuchen zwei Mounts von einem einzigen NFS-Export und versuchen, den Kontext für jeden einzelnen zu überschreiben
sudo mount server:/export/web /local/web -o context="system_u:object_r:httpd_sys_content_t:s0"
sudo mount server:/export/database /local/database -o context="system_u:object_r:mysqld_db_t:s0"

Der zweite Mount-Befehl schlägt fehl, und Folgendes wird in [[/var/log/messages]] protokolliert
kernel
SELinux
mount invalid
* Gleicher Superblock, unterschiedliche Sicherheitseinstellungen für (dev 0:15, Typ nfs)

Um mehrere Mounts aus einem einzigen NFS-Export durchzuführen, wobei jeder Mount einen anderen Kontext hat, verwenden Sie die [[-o nosharecache,context]]-Optionen
* Das folgende Beispiel mountet mehrere Mounts aus einem einzigen NFS-Export, wobei jeder Mount einen anderen Kontext hat (wodurch ein einzelner Dienst auf jeden einzelnen zugreifen kann)
sudo mount server:/export/web /local/web -o nosharecache,context=„system_u:object_r:httpd_sys_content_t:s0“
sudo mount server:/export/database /local/database -o \ nosharecache,context=„system_u:object_r:mysqld_db_t:s0“

In diesem Beispiel wird [[server:/export/web]] lokal im Verzeichnis [[/local/web/]] eingebunden, wobei alle Dateien mit dem Typ [[httpd_sys_content_t]] gekennzeichnet sind, was dem Apache-HTTP-Server Zugriff gewährt. [[server:/export/database]] wird lokal in [[/local/database/]] eingebunden, wobei alle Dateien mit dem Typ [ [mysqld_db_t]] gekennzeichnet, was MariaDB den Zugriff ermöglicht
* Diese Typänderungen werden nicht auf die Festplatte geschrieben

; Wichtig

Die Option [[nosharecache]] ermöglicht es Ihnen, dasselbe Unterverzeichnis eines Exports mehrfach mit unterschiedlichen Kontexten einzuhängen, beispielsweise [[/export/web/]] mehrfach
* Hängen Sie dasselbe Unterverzeichnis eines Exports nicht mehrfach mit unterschiedlichen Kontexten ein, da dies zu einer überlappenden Einbindung führt, bei der Dateien unter zwei verschiedenen Kontexten zugänglich sind

==== Kontext-Einbindungen dauerhaft machen ====
Um Kontext-Mounts über erneutes Mounten und Neustarts hinweg persistent zu machen, fügen Sie Einträge für die Dateisysteme in die Datei [[/etc/fstab]] oder eine Automounter-Zuordnung ein und verwenden Sie den erforderlichen Kontext als Mount-Option

Das folgende Beispiel fügt einen Eintrag in [[/etc/fstab]] für eine NFS-Kontext-Einbindung hinzu
server:/export /local/mount/ nfs context="system_u:object_r:httpd_sys_content_t:s0" 0 0

{{navigation|Linux/SELinux/04/09 Dateisysteme|Linux/SELinux/04/10 Labels beibehalten}}

[[Kategorie:Linux/SELinux/04]]

Linux/SELinux/04/07 Kontexte

2026-03-29T15:35:24Z

DanielZorin:

Linux/SELinux/04/07 Kontexte

2026-03-29T15:34:53Z

DanielZorin:

'''Sicherheitskontext''' - Struktur und Auslesen des Sicherheitskontexts

= Debian =
== 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'''

; Wichtig
:* SELinux-Richtlinienregeln (MAC) werden erst '''nach''' den klassischen Linux-Zugriffsrechten (DAC — Eigentümer, Gruppe, rwx) überprüft.
:* Wenn bereits die DAC-Regeln den Zugriff verweigern, blockiert das System sofort. SELinux wird in diesem Fall gar nicht erst angewendet und erzeugt folglich auch keine AVC-Meldungen im Audit-Log.

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

=== Kontextzeichenfolge ===
; Anatomie der Kontextzeichenfolge
Das vollständige Label eines Sicherheitskontexts besteht aus vier (manchmal fünf) durch Doppelpunkte getrennten Elementen

; Typische Struktur
<syntaxhighlight lang="bash" highlight="1" line>
user : role : type : level
</syntaxhighlight>

== 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 ===
; Vererbung (Inheritance)
: 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, erhält die neue Datei automatisch denselben Typ.

Zum Anzeigen des Kontexts von Dateien wird der Befehl ls -Z verwendet
<syntaxhighlight lang="bash" highlight="1" line copy>
ls -Z /var/log
</syntaxhighlight>

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

=== Interpretation der Typen ===
Bei der Analyse von Kontexten sollte man auf die Suffixe der Typen achten, da diese häufig auf ihren Zweck hinweisen
{| class="wikitable options gnu big"
|-
! 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
{| class="wikitable big options"
!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
<syntaxhighlight lang="bash" highlight="1" line copy>
getfattr -n security.selinux /etc/passwd
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" line copy>
touch testfile
setfattr -n security.selinux -v "unconfined_u:object_r:user_home_t:s0" testfile
</syntaxhighlight>

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

== Anwendung ==
=== Modus prüfen ===
<syntaxhighlight lang="bash" highlight="1" copy>
getenforce
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy>
touch /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
ls -Z /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="console" highlight="" line>
unconfined_u:object_r:user_tmp_t:s0 /tmp/testfile
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy>
setfattr -n security.selinux -v "system_u:object_r:shadow_t:s0" /tmp/testfile
</syntaxhighlight>

Zum Setzen von Attributen kann auch das Werkzeug chcon verwendet werden; in diesem Fall sieht der Befehl wie folgt aus
<syntaxhighlight lang="bash" highlight="1" copy>
chcon -t shadow_t /tmp/testfile
</syntaxhighlight>

Über das Werkzeug chcon sprechen wir etwas später noch genauer besprochen

Prüfung, ob die Attribute korrekt gesetzt wurden
<syntaxhighlight lang="console" highlight="1" copy>
sudo ls -Z /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="console" highlight="" line>
unconfined_u:object_r:shadow_t:s0 /tmp/testfile
</syntaxhighlight>

Schließlich muss nun ein Verstoß provoziert werden; dazu versuchen wir, die Datei zu lesen oder zu ändern
<syntaxhighlight lang="bash" highlight="1" copy>
echo "test" > /tmp/testfile
</syntaxhighlight>

Nun betrachten wir die AVC-Ereignisse mit dem Werkzeug ausearch
<syntaxhighlight lang="bash" highlight="1" copy>
ausearch -m AVC -ts recent
</syntaxhighlight>

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
<syntaxhighlight lang="console" highlight="1" copy>
sudo id -Z
</syntaxhighlight>
<syntaxhighlight lang="console" highlight="" line>
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy>
cp /usr/bin/cat /tmp/fake_httpd
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
setfattr -n security.selinux -v "system_u:object_r:httpd_t:s0" /tmp/fake_httpd sudo oder chcon -t httpd_t /tmp/fake_httpd
</syntaxhighlight>

Prüfung
<syntaxhighlight lang="bash" highlight="" copy>
systemd-run -p SELinuxContext=system_u:system_r:httpd_t:s0 /tmp/fake_httpd /tmp/testfile
</syntaxhighlight>
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
<syntaxhighlight lang="bash" highlight="1" copy>
ausearch -m AVC -ts recent -c fake_httpd
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="" line>
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
</syntaxhighlight>

* { 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
<syntaxhighlight lang="bash" highlight="1" line copy>
setfattr -n security.selinux -v "system_u:object_r:user_home_t:s0" /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
chmod 777 /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
systemd-run -p SELinuxContext=system_u:system_r:httpd_t:s0 /tmp/fake_httpd /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
ausearch -m AVC -ts recent -c fake_httpd
</syntaxhighlight>

Und erneut erscheint im Log eine Meldung über einen Verstoß
<syntaxhighlight lang="bash" highlight="" line>
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
</syntaxhighlight>

; 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" copy>
setenforce 1 && setenforce 0
</syntaxhighlight>

=== 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
<syntaxhighlight lang="bash" highlight="1" copy line>
mkdir -p /tmp/web_content/images
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
cd /tmp/web_content/
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
touch manual
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
touch test.conf
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
touch images/image.png
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Zd /tmp/web_content/
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z -1 /tmp/web_content/
</syntaxhighlight>

Diesem Verzeichnis wurde der Typ '''user_tmp_t''' vererbt, ebenso den darin enthaltenen Dateien

Versuchen wir, den vollständigen Kontext manuell zu setzen
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon system_u:object_r:httpd_sys_content_t:s0 manual
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z -1
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -t shadow_t manual
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -R -v -t httpd_sys_content_t /tmp/web_content
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z -1
</syntaxhighlight>

Um den Kontext von einem bereits korrekt gelabelten Objekt zu kopieren, kann die Option '''--reference=RFILE''' verwendet werden
<syntaxhighlight lang="bash" highlight="1" copy line>
touch /tmp/ref
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -R --reference=/tmp/ref /tmp/web_content
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z -1
</syntaxhighlight>

; Parameter für den Umgang mit Symlinks
{| class="wikitable sortable options gnu big"
|-
! 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
|}

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

# '''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
# '''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
# '''Regulärer Ausdruck (Regular Expression).''' Die erste Spalte beschreibt den Pfad
#* SELinux verwendet reguläre Ausdrücke im PCRE*-Format (Perl-compatible regular expression)
#* Beispielsweise bedeutet der Ausdruck /var/www(/.*)?: sowohl das Verzeichnis /var/www selbst als auch absolut jede Datei oder jedes Unterverzeichnis darin
#* Wichtig zur PCRE-Verarbeitung:
#*:* Das einzige verwendete Flag ist '''PCRE2_DOTALL'''. Dadurch stimmt der Platzhalter ''.'' (Punkt) mit jedem beliebigen Zeichen überein, '''einschließlich Zeilenumbrüchen'''
#*:* Zeichenfolgen, die Pfade darstellen, werden strikt als Bytes verarbeitet. Das bedeutet, dass Nicht-ASCII-Zeichen (wie z.B. deutsche Umlaute) unter Umständen nicht durch einen einzelnen Platzhalter abgeglichen werden können
# '''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.''
# '''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
{| class="wikitable options big col1center"
! 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

# '''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
# '''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(/.*)?
# '''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

# '''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
# '''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
# '''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
{| class="wikitable big options"
!matchpathcon -m
!file_contexts
|-
|file
|--
|-
|dir
|-d
|-
|lnk_file
|-l
|-
|sock_file
|-s
|-
|pipe
|-p
|-
|chr_file
|-c
|-
|blk_file
|-b
|}
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

== Verwaltung von Kontexten mit semanage ==
Nun ist es endlich an der Zeit, die Verwaltung der File-Context-Datenbank zu betrachten

Wie bereits zuvor besprochen, überschreibt chcon direkt die erweiterten Attribute (xattr) auf dem Datenträger, teilt der SELinux-Policy-Datenbank (file_contexts) jedoch absolut nichts darüber mit

Änderungen, die mit chcon vorgenommen werden, sind im Maßstab des Systemlebenszyklus nur temporär

Sie werden bei jedem der folgenden Ereignisse unwiderruflich zerstört (durch Referenzwerte aus der Datenbank überschrieben)
* der Administrator startet das Dienstprogramm restorecon manuell für dieses Verzeichnis;
* es erfolgt ein Systemupdate eines Pakets (zum Beispiel des Webservers), dessen Installer eine Prüfung der Kontexte auslöst;
* beim Booten wird ein vollständiges Relabeling des Dateisystems initiiert (durch Erzeugen der Datei /.autorelabel)

=== semanage fcontext ===
Damit ein Kontext alle Updates und Relabeling-Vorgänge übersteht, muss man dem SELinux-System selbst beibringen, dass ein nicht standardmäßiger Pfad nun ein bestimmtes Label haben soll

Dafür wird das Werkzeug semanage (SELinux Policy Management Tool) verwendet
* Es ist das allgemeine Werkzeug zur lokalen Verwaltung von Elementen der SELinux-Policy, darunter: login mappings, SELinux users, ports, interfaces, modules, booleans, permissive types und file contexts
* Für den aktuellen Schritt ist insbesondere der Bereich fcontext relevant

==== Verwendung ====
Zur Demonstration versuchen wir, ein nicht standardmäßiges Verzeichnis mit hochsensiblen Daten zu schützen

Stellen wir uns folgende Situation vor: Entwickler haben ein internes Authentifizierungssystem ausgerollt, das Sicherungskopien der Passwort-Hashes von Benutzern in einem nicht standardmäßigen Verzeichnis speichert — /opt/app_auth/vault/
<syntaxhighlight lang="bash" highlight="" copy line>
mkdir -p /opt/app_auth/vault
ls -Zd /opt/app_auth/vault/
</syntaxhighlight>

Wenn wir uns an die Analyse der Datei file_contexts aus den vorherigen Schritten erinnern, erhalten das Verzeichnis /opt/ und sein gesamter Inhalt standardmäßig den Kontext usr_t

; Das ist ein öffentlicher Kontext
* '''Die meisten laufenden Dienste und Benutzer dürfen Dateien mit diesem Label lesen.'''
* '''Passwörter dort zu speichern ist unzulässig.'''
* Daher muss für dieses Verzeichnis eine grundlegende Regel erstellt werden

Verwenden wir dazu die Parameter -a (add) und -t (Feld type)
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -a -t shadow_t "/opt/app_auth/vault(/.*)?"
</syntaxhighlight>

"/opt/app_auth/vault(/.*)?" — ein regulärer Ausdruck, der das Verzeichnis selbst und absolut alle darin enthaltenen Dateien umfasst

Nun prüfen wir den Kontext des Verzeichnisses
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Zd /opt/app_auth/vault/
</syntaxhighlight>
...und sehen, dass sich nichts geändert hat
* Das liegt daran, dass wir zwar einen Eintrag in die Datenbank hinzugefügt haben, das bloße Hinzufügen eines Eintrags jedoch kein Relabeling auslöst
* Um die Änderungen anzuwenden, wird das uns bereits bekannte Werkzeug restorecon verwendet
<syntaxhighlight lang="bash" highlight="" copy line>
restorecon -Rv /opt/app_auth/vault/
ls -Zd /opt/app_auth/vault/
</syntaxhighlight>

Ergebnis
<syntaxhighlight lang="bash" highlight="" copy line>
# ls -Zd /opt/app_auth/vault/
unconfined_u:object_r:shadow_t:s0 /opt/app_auth/vault/
</syntaxhighlight>

Prüfen wir, ob der Eintrag in der File-Context-Datenbank vorhanden ist
<syntaxhighlight lang="bash" highlight="" copy line>
cat /etc/selinux/default/contexts/files/file_contexts.local

# This file is auto-generated by libsemanage
# Do not edit directly

/opt/app_auth/vault(/.*)? system_u:object_r:shadow_t:s0
</syntaxhighlight>

'''Jetzt sind die vertraulichen Daten zuverlässig geschützt!'''

==== Optionen ====
Das Werkzeug semanage verfügt über verschiedene nützliche Optionen; konzentrieren wir uns auf die wichtigsten

Welche nicht standardmäßigen Regeln manuell hinzugefügt wurden, kann mit der Option -l (list) zusammen mit dem Modifikator -C (Custom) angezeigt werden
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -lC
</syntaxhighlight>

Den Kontexttyp für den bereits in der lokalen Datenbank registrierten Pfad /srv/myweb(/.*)? kann man mit der Option -m (modify) aktualisieren
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -m -t httpd_sys_rw_content_t "/srv/myweb(/.*)?"
</syntaxhighlight>

Wichtig ist, dass der reguläre Ausdruck genau mit dem Eintrag in der Datenbank übereinstimmt, dessen Kontext wir ändern wollen

Wenn ein Dienst außer Betrieb genommen wurde und das nicht standardmäßige Verzeichnis nicht mehr benötigt wird, kann die Regel mit der Option -d gelöscht werden
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -d "/opt/app_auth/vault(/.*)?"
</syntaxhighlight>

=== Äquivalente Pfade (Equivalence Rules) ===
Bei der Arbeit mit mehreren Verzeichnissen entsteht häufig die Situation, dass
* bereits eine korrekt gekennzeichnete Struktur existiert
* eine Kopie dieser Struktur an einem anderen Ort erstellt werden muss

==== Beispielaufgabe ====
Es gibt den Standardpfad des Webservers /var/www, wir haben jedoch beschlossen, die Dateien unserer neuen Website in einem nicht standardmäßigen Verzeichnis abzulegen, zum Beispiel auf einer separaten Festplatte, die unter /srv/myweb eingehängt ist

Wir erstellen zur Veranschaulichung mehrere Ordner im ursprünglichen Verzeichnis /var/www und bereiten das neue Verzeichnis /srv/myweb vor
<syntaxhighlight lang="bash" highlight="" copy line>
mkdir -p /var/www/sessions && mkdir -p /var/www/cgi-bin
restorecon -v -R /var/www
ls -Z1 /var/www
mkdir -p /srv/myweb
cp -r /var/www/* /srv/myweb/
ls -Z1 /srv/myweb
</syntaxhighlight>

Standardmäßig sind für das Verzeichnis /var/www und alle seine Unterverzeichnisse (html, cgi-bin usw.) im System bereits Dutzende komplexer regulärer Ausdrücke definiert, die die korrekten Kontexte zuweisen (zum Beispiel httpd_cache_t für /var/www/uploads(/.*)?)
* Alle regulären Ausdrücke aus /var/www manuell für das neue Verzeichnis /srv/myweb umzuschreiben, wäre aufwendig, unhandlich und fehleranfällig

Für die Lösung solcher Aufgaben werden Äquivalenzregeln verwendet (Parameter -e des Befehls semanage fcontext)
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -a -e /var/www /srv/myweb
</syntaxhighlight>

Änderungen anwenden
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -v -R /srv/myweb
</syntaxhighlight>

Sehen wir uns an, wie das in der Datenbank aussieht
<syntaxhighlight lang="bash" highlight="" copy line>
# semanage fcontext -lC
SELinux fcontext type Context
/opt/app_auth/vault(/.*)? all files system_u:object_r:shadow_t:s0

SELinux Local fcontext Equivalence
/srv/myweb = /var/www
</syntaxhighlight>

Eine Äquivalenzregel funktioniert wie ein transparenter Alias: Wenn SELinux irgendeine Datei innerhalb von /srv/myweb/ prüft, ersetzt es in deren Pfad virtuell /srv/myweb durch /var/www und sucht erst danach Übereinstimmungen in seiner umfangreichen Datenbank regulärer Ausdrücke

Wenn es erforderlich ist, die Äquivalenzregel zu entfernen, geschieht dies mit dem bereits bekannten Parameter -d; man muss ihn lediglich anstelle des Parameters -a aus dem ursprünglichen Befehl verwenden
<syntaxhighlight lang="bash" highlight="" copy line>
semanage fcontext -d -e /var/www /srv/myweb
semanage fcontext -lC
</syntaxhighlight>

=== Export und Import lokaler Policies ===
Das Dienstprogramm semanage kann Policies mit den Befehlen semanage export und semanage import in eine Datei exportieren beziehungsweise aus einer Datei importieren
* In der Praxis wird das zum Beispiel verwendet, wenn ein Administrator plant, Policies von einem Testserver auf die Produktionsumgebung zu übertragen

==== Export ====
Verwendungsbeispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage export -f /tmp/selinux_local_rules.txt
</syntaxhighlight>

Prüfen wir, was sich darin befindet
<syntaxhighlight lang="bash" highlight="" copy line>
cat /tmp/selinux_local_rules.txt
boolean -D
login -D
interface -D
...
fcontext -a -f a -t shadow_t -r 's0' '/opt/app_auth/vault(/.*)?'
module -d acpi
module -d aisexec
module -d amtu
..
</syntaxhighlight>

Wie man sehen kann, ist die Datei logisch in drei Teile gegliedert

* '''Bereinigungsblock''' (Einträge mit dem Schlüssel -D) – beim Import der Datei auf einem neuen Server (über semanage import) soll das Policy-System zu einer ''exakten Kopie'' des Quellservers werden
* Daher müssen alle lokalen Einstellungen gelöscht werden
* Der Schlüssel -D wird als Delete interpretiert
* '''Lokale Regeln''' (im Beispiel die einzige Regel fcontext)
* '''Block deaktivierter Policy-Module''' (Einträge mit dem Schlüssel -d) – das Policy-Set default policy in Debian ist gehärtet (hardened) und deaktiviert ungenutzte Module
* In RHEL macht die Policy targeted genau das Gegenteil: Dort sind standardmäßig von Anfang an alle Module aktiviert, unabhängig davon, ob die entsprechende Software installiert ist oder nicht

==== Import ====
Für den Import wird der Befehl semanage import verwendet; seine Syntax sieht identisch zum Export aus
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage import -f /tmp/selinux_local_rules.txt
</syntaxhighlight>

Wenn uns die importierten Policies zusagen und alles Erforderliche mit matchpathcon -V geprüft wurde, wenden wir die Änderungen an
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -Rv /
</syntaxhighlight>

[[Kategorie:Linux/SELinux/Praxis]]

= RHEL =
=== 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
<syntaxhighlight lang="bash" highlight="" copy line>
ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
</syntaxhighlight>

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

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‘' '' aus, 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
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -t httpd_sys_content_t ‚'file-name‘'
</syntaxhighlight>

* Führen Sie den Befehl ''chcon -R -t ‚'type‘' ‚'directory-name‘''' aus, um den Typ des Verzeichnisses und dessen Inhalt zu ändern, wobei ‚'type‘' ein SELinux-Typ ist, wie beispielsweise ''httpd_sys_content_t'', und ‚'Verzeichnisname‘' ein Verzeichnisname ist
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -R -t httpd_sys_content_t ‚'Verzeichnisname‘'
</syntaxhighlight>

; Ä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
# Erstellen Sie eine neue Datei und zeigen Sie deren SELinux-Kontext an
<syntaxhighlight lang="bash" highlight="" copy line>
touch file1

ls -Z file1
-rw -rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
</syntaxhighlight>

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‘'
# 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
<syntaxhighlight lang="bash" highlight="" copy line>
chcon -t samba_share_t file1

ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:samba_share_t:s0 file1
</syntaxhighlight>

# Verwenden Sie den folgenden Befehl, um den SELinux-Kontext für die Datei ''file1'' wiederherzustellen
* Verwenden Sie die Option ''-v'', um die Änderungen anzuzeigen
<syntaxhighlight lang="bash" highlight="" copy line>
restorecon -v file1
restorecon reset file1 context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:user_home_t:s0
</syntaxhighlight>

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

# Geben Sie als root den folgenden Befehl ein, um den Typ des Verzeichnisses ''web/'' (und dessen Inhalt) in ''httpd_sys_content_t'' zu ändern
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

# Um die Standard-SELinux-Kontexte wiederherzustellen, verwenden Sie das Dienstprogramm ''restorecon'' als root
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -C -l
</syntaxhighlight>

Ä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
# Geben Sie den folgenden Befehl ein und achten Sie darauf, den vollständigen Pfad zur Datei oder zum Verzeichnis zu verwenden
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -a ‚'Optionen‘' ‚'Dateiname‘ ‚|‘'Verzeichnisname'‚
</syntaxhighlight>

# Verwenden Sie das Dienstprogramm ''restorecon'', um die Kontextänderungen anzuwenden
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo restorecon -v ‘'Dateiname'‚|‘'Verzeichnisname'‚
</syntaxhighlight>

===== 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
<syntaxhighlight lang="bash" highlight="" copy line>
sudo touch /etc/file1

ls -Z /etc/file1
-rw-r--r-- root root unconfined_u:object_r:etc_t:s0 /etc/file1
</syntaxhighlight>

Um Informationen zu einem Verzeichnis aufzulisten, verwenden Sie den folgenden Befehl
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -dZ ‚'Verzeichnisname‘'
</syntaxhighlight>

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

# Verwenden Sie als root das Dienstprogramm ''restorecon'', um den Typ zu ändern
* Da ''semanage'' einen Eintrag für ''/etc/file1'' in ''file_contexts.local'' hinzugefügt hat, ändert ''restorecon'' den Typ in ''samba_share_t''
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

; Ä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
# 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
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

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

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
<syntaxhighlight lang="bash" highlight="1" copy line>
/web(/.*)? system_u:object_r:httpd_sys_content_t:s0
</syntaxhighlight>

# Verwenden Sie als root das Dienstprogramm ''restorecon'', um den Typ von ''web/'' sowie aller darin enthaltenen Dateien zu ändern
* Der Parameter ''-R'' steht für rekursiv, was bedeutet, dass alle Dateien und Verzeichnisse unter ''web/'' mit dem Typ ''httpd_sys_content_t'' gekennzeichnet werden
* Da ''semanage'' einen Eintrag für ''/web(/.*)?'' in ''file.contexts.local'' hinzugefügt hat, ändert ''restorecon'' die Typen in ''httpd_sys_content_t''
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -d „/web(/.*)?“
</syntaxhighlight>

# Um den Kontext zu entfernen, geben Sie als Root den folgenden Befehl ein, wobei ‚'Dateiname‘'|‚'Verzeichnisname‘' der erste Teil in ''file_contexts.local'' ist
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -d ‚'Dateiname‘'|‚'Verzeichnisname‘'
</syntaxhighlight>

Das Folgende ist ein Beispiel für einen Kontext in ''file_contexts. local''
<syntaxhighlight lang="bash" highlight="1" copy line>
/test system_u:object_r:httpd_sys_content_t:s0
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -d /test
</syntaxhighlight>

# 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
* Basierend auf der Systemrichtlinie generiert ''semanage'' die Dateien ''file_contexts.homedirs'' und ''file_contexts''-Dateien

Systemadministratoren können Dateikontextdefinitionen mit dem Befehl ''semanage fcontext'' anpassen
* Solche Anpassungen werden in der Datei ''file_contexts.local'' gespeichert

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“
* das Ändern und Hinzufügen einer Dateikontextdefinition durch eine Systemrichtlinienoperation, siehe Abschnitt „''Pflege von SELinux-Labels''“ oder Abschnitt „''Priorisierung und Deaktivierung von SELinux-Richtlinienmodulen''“

[[Kategorie:Linux/SELinux/04]]

Linux/SELinux/11 Fehlerbehebung

2026-03-29T14:39:24Z

DanielZorin: /* Eigene Policy-Module mit audit2allow */

'''SELinux/11 Fehlerbehebung'''

== Beschreibung ==
* Vorgänge, bei einer Zugriffsverweigerung
* Häufige Ursachen für Probleme
* Informationen zur korrekten Kennzeichnung finden
* Analyse von SELinux-Verweigerungen
* Erstellen benutzerdefinierter Policy-Module

; Vorgänge, bei einer Zugriffsverweigerung
SELinux-Entscheidungen, wie das Zulassen oder Verweigern von Zugriff, werden zwischengespeichert
* Dieser Cache wird als Access Vector Cache (AVC) bezeichnet
* Wenn SELinux den Zugriff verweigert, werden Verweigerungsmeldungen protokolliert
* Diese Verweigerungen werden auch als „[[AVC-Verweigerungen]]“ bezeichnet

; Protokolle
... und je nach den laufenden Daemons an unterschiedlichen Orten protokolliert:
{| class="wikitable options big"
|-
! | Daemon
! | Protokollort
|-
|| auditd aktiv
|| '''/var/log/audit/audit.log'''
|-
|| auditd aus; rsyslogd ein
|| '''/var/log/messages'''
|-
|| setroubleshootd, rsyslogd und auditd ein
|| '''/var/log/audit/audit.log'''
* Besser lesbare Verweigerungsmeldungen werden ebenfalls an '''/var/log/messages''' gesendet
|-
|}

Wenn Sie das X Window System ausführen, die Pakete [[setroubleshoot]] und [[setroubleshoot-server]] installiert haben und die Daemons '''[[setroubleshootd]]''' und '''[[auditd]''' laufen, wird eine Warnung angezeigt, wenn der Zugriff von SELinux verweigert wird:

[[Image:Bild1.png|top]]

Ein Klick auf '''Anzeigen''' zeigt eine detaillierte Analyse der Gründe für die Zugriffsverweigerung durch SELinux sowie eine mögliche Lösung zur Gewährung des Zugriffs an
* Wenn Sie das X Window System nicht verwenden, ist es weniger offensichtlich, wenn der Zugriff durch SELinux verweigert wird

Beispielsweise können Benutzer, die Ihre Website besuchen, eine Fehlermeldung ähnlich der folgenden erhalten:
Zugriff verweigert

Sie haben keine Berechtigung, auf ‚'Dateiname‘' auf diesem Server zuzugreifen

In solchen Situationen sollten Sie, sofern DAC-Regeln (Standard-Linux-Berechtigungen) den Zugriff erlauben, die Dateien
* '''/var/log/messages'''
* '''/var/log/audit/audit.log'''
auf Fehlermeldungen wie
* '''„SELinux is preventing“'''
* '''„denied“'''
überprüfen

Dies können Sie tun, indem Sie als Root-Benutzer die folgenden Befehle ausführen:
sudo grep „SELinux is preventing“ /var/log/messages
sudo grep „denied“ /var/log/audit/audit.log

== Analyse ==
[[Linux/SELinux/11 Fehlerbehebung/Analyse]]

== Lösungen ==
[[Linux/SELinux/11 Fehlerbehebung/Lösungen]]

== Eigene Policy-Module mit audit2allow ==

;Prinzip
Wenn Standardlösungen (wie Booleans oder Dateikontexte) nicht ausreichen, analysiert ''audit2allow'' die Audit-Protokolle und generiert automatisch Regeln, um zuvor blockierte Aktionen systemweit zuzulassen.

; Installation
Unter Debian ist das Tool Teil der Python-Utilities für SELinux:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo apt install policycoreutils-python-utils
</syntaxhighlight>

; Analyse
Prüfen Sie zunächst die menschenlesbare Erklärung der Blockaden, um die Ursache zu verstehen:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo audit2allow -w -a
</syntaxhighlight>

; Modul generieren
Filtern Sie die Logs gezielt nach dem betroffenen Dienst (z. B. ''nginx''), um keine unerwünschten Rechte freizugeben, und erstellen Sie das Modul:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo grep mein_prozess /var/log/audit/audit.log | audit2allow -M mein_modul
</syntaxhighlight>

Dies erzeugt eine Quellcode-Datei (''.te'') und das kompilierte Policy-Paket (''.pp'')

; Modul aktivieren
Laden Sie das kompilierte Paket abschließend in den Kernel:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semodule -i mein_modul.pp
</syntaxhighlight>

; Initiale Einrichtung
Nach einer frischen SELinux-Installation und der Deinstallation von AppArmor wird das System oft mit unklaren AVC-Meldungen geflutet. Um das System initial wieder nutzbar zu machen, können Sie alle bisherigen Blockaden pauschal erfassen:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo grep "AVC" /var/log/audit/audit.log | audit2allow -M my_custom_policy
</syntaxhighlight>

Laden Sie auch dieses Modul anschließend mit
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semodule -i my_custom_policy.pp
</syntaxhighlight>
;Hinweis
Diese "Holzhammer-Methode" eignet sich nur für die allererste Stabilisierung des Systems. Im späteren Betrieb sollten Sie Ausnahmen immer strikt nach Diensten getrennt erstellen.

<noinclude>

== Anhang ==
=== Siehe auch ===
<div style="column-count:2">
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
</div>
----
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
----
# Dateien in '''/etc/selinux/targeted/contexts/files/'''
#* definieren Kontexte für Dateien und Verzeichnisse
#* Dateien in diesem Verzeichnis werden von den Dienstprogrammen '''restorecon''' und '''setfiles''' gelesen, um Dateien und Verzeichnisse in ihre Standardkontexte zurückzusetzen
# Der Befehl '''semanage port -a''' fügt einen Eintrag zur Datei '''/etc/selinux/targeted/modules/active/ports.local''' hinzu
#* Beachten Sie, dass diese Datei standardmäßig nur von root eingesehen werden kann

=== Dokumentation ===
; Man-Page
# [https://manpages.debian.org/stable/auditd/ausearch.8.en.html ausearch(8)]
# [https://manpages.debian.org/trixie/auditd/aureport.8.en.html aureport(8)]
# sealert(8)
# [https://manpages.debian.org/trixie/policycoreutils-python-utils/audit2allow.1.en.html audit2allow(1)]

=== Links ===
==== Projekt ====
==== Weblinks ====



[[Kategorie:Linux/SELinux]]

</noinclude>

Linux/SELinux/11 Fehlerbehebung

2026-03-29T14:38:46Z

DanielZorin:

'''SELinux/11 Fehlerbehebung'''

== Beschreibung ==
* Vorgänge, bei einer Zugriffsverweigerung
* Häufige Ursachen für Probleme
* Informationen zur korrekten Kennzeichnung finden
* Analyse von SELinux-Verweigerungen
* Erstellen benutzerdefinierter Policy-Module

; Vorgänge, bei einer Zugriffsverweigerung
SELinux-Entscheidungen, wie das Zulassen oder Verweigern von Zugriff, werden zwischengespeichert
* Dieser Cache wird als Access Vector Cache (AVC) bezeichnet
* Wenn SELinux den Zugriff verweigert, werden Verweigerungsmeldungen protokolliert
* Diese Verweigerungen werden auch als „[[AVC-Verweigerungen]]“ bezeichnet

; Protokolle
... und je nach den laufenden Daemons an unterschiedlichen Orten protokolliert:
{| class="wikitable options big"
|-
! | Daemon
! | Protokollort
|-
|| auditd aktiv
|| '''/var/log/audit/audit.log'''
|-
|| auditd aus; rsyslogd ein
|| '''/var/log/messages'''
|-
|| setroubleshootd, rsyslogd und auditd ein
|| '''/var/log/audit/audit.log'''
* Besser lesbare Verweigerungsmeldungen werden ebenfalls an '''/var/log/messages''' gesendet
|-
|}

Wenn Sie das X Window System ausführen, die Pakete [[setroubleshoot]] und [[setroubleshoot-server]] installiert haben und die Daemons '''[[setroubleshootd]]''' und '''[[auditd]''' laufen, wird eine Warnung angezeigt, wenn der Zugriff von SELinux verweigert wird:

[[Image:Bild1.png|top]]

Ein Klick auf '''Anzeigen''' zeigt eine detaillierte Analyse der Gründe für die Zugriffsverweigerung durch SELinux sowie eine mögliche Lösung zur Gewährung des Zugriffs an
* Wenn Sie das X Window System nicht verwenden, ist es weniger offensichtlich, wenn der Zugriff durch SELinux verweigert wird

Beispielsweise können Benutzer, die Ihre Website besuchen, eine Fehlermeldung ähnlich der folgenden erhalten:
Zugriff verweigert

Sie haben keine Berechtigung, auf ‚'Dateiname‘' auf diesem Server zuzugreifen

In solchen Situationen sollten Sie, sofern DAC-Regeln (Standard-Linux-Berechtigungen) den Zugriff erlauben, die Dateien
* '''/var/log/messages'''
* '''/var/log/audit/audit.log'''
auf Fehlermeldungen wie
* '''„SELinux is preventing“'''
* '''„denied“'''
überprüfen

Dies können Sie tun, indem Sie als Root-Benutzer die folgenden Befehle ausführen:
sudo grep „SELinux is preventing“ /var/log/messages
sudo grep „denied“ /var/log/audit/audit.log

== Analyse ==
[[Linux/SELinux/11 Fehlerbehebung/Analyse]]

== Lösungen ==
[[Linux/SELinux/11 Fehlerbehebung/Lösungen]]

== Eigene Policy-Module mit audit2allow ==

;Prinzip
Wenn Standardlösungen (wie Booleans oder Dateikontexte) nicht ausreichen, analysiert ''audit2allow'' die Audit-Protokolle und generiert automatisch Regeln, um zuvor blockierte Aktionen systemweit zuzulassen.

; Installation
Unter Debian ist das Tool Teil der Python-Utilities für SELinux:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo apt install policycoreutils-python-utils
</syntaxhighlight>

; Analyse
Prüfen Sie zunächst die menschenlesbare Erklärung der Blockaden, um die Ursache zu verstehen:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo audit2allow -w -a
</syntaxhighlight>

; Modul generieren
Filtern Sie die Logs gezielt nach dem betroffenen Dienst (z. B. ''nginx''), um keine unerwünschten Rechte freizugeben, und erstellen Sie das Modul:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo grep mein_prozess /var/log/audit/audit.log | audit2allow -M mein_modul
</syntaxhighlight>

Dies erzeugt eine Quellcode-Datei (''.te'') und das kompilierte Policy-Paket (''.pp'')

; Modul aktivieren
Laden Sie das kompilierte Paket abschließend in den Kernel:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semodule -i mein_modul.pp
</syntaxhighlight>

; Initiale Einrichtung
Nach einer frischen SELinux-Installation und der Deinstallation von AppArmor wird das System oft mit unklaren AVC-Meldungen geflutet. Um das System initial wieder nutzbar zu machen, können Sie alle bisherigen Blockaden pauschal erfassen:
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo grep "AVC" /var/log/audit/audit.log | audit2allow -M my_custom_policy
</syntaxhighlight>

Laden Sie auch dieses Modul anschließend mit
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semodule -i my_custom_policy.pp
</syntaxhighlight>
'''Hinweis:''' Diese "Holzhammer-Methode" eignet sich nur für die allererste Stabilisierung des Systems. Im späteren Betrieb sollten Sie Ausnahmen immer strikt nach Diensten getrennt erstellen.

<noinclude>

== Anhang ==
=== Siehe auch ===
<div style="column-count:2">
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
</div>
----
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
----
# Dateien in '''/etc/selinux/targeted/contexts/files/'''
#* definieren Kontexte für Dateien und Verzeichnisse
#* Dateien in diesem Verzeichnis werden von den Dienstprogrammen '''restorecon''' und '''setfiles''' gelesen, um Dateien und Verzeichnisse in ihre Standardkontexte zurückzusetzen
# Der Befehl '''semanage port -a''' fügt einen Eintrag zur Datei '''/etc/selinux/targeted/modules/active/ports.local''' hinzu
#* Beachten Sie, dass diese Datei standardmäßig nur von root eingesehen werden kann

=== Dokumentation ===
; Man-Page
# [https://manpages.debian.org/stable/auditd/ausearch.8.en.html ausearch(8)]
# [https://manpages.debian.org/trixie/auditd/aureport.8.en.html aureport(8)]
# sealert(8)
# [https://manpages.debian.org/trixie/policycoreutils-python-utils/audit2allow.1.en.html audit2allow(1)]

=== Links ===
==== Projekt ====
==== Weblinks ====



[[Kategorie:Linux/SELinux]]

</noinclude>

Linux/SELinux/04/07 Kontexte

2026-03-29T14:26:31Z

DanielZorin:

'''Sicherheitskontext''' - Struktur und Auslesen des Sicherheitskontexts

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

=== Kontextzeichenfolge ===
; Anatomie der Kontextzeichenfolge
Das vollständige Label eines Sicherheitskontexts besteht aus vier (manchmal fünf) durch Doppelpunkte getrennten Elementen

; Typische Struktur
<syntaxhighlight lang="bash" highlight="1" line>
user : role : type : level
</syntaxhighlight>

== 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
<syntaxhighlight lang="bash" highlight="1" line copy>
ls -Z /var/log
</syntaxhighlight>

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

=== Interpretation der Typen ===
Bei der Analyse von Kontexten sollte man auf die Suffixe der Typen achten, da diese häufig auf ihren Zweck hinweisen
{| class="wikitable options gnu big"
|-
! 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
{| class="wikitable big options"
!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
<syntaxhighlight lang="bash" highlight="1" line copy>
getfattr -n security.selinux /etc/passwd
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" line copy>
touch testfile
setfattr -n security.selinux -v "unconfined_u:object_r:user_home_t:s0" testfile
</syntaxhighlight>

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

== Anwendung ==
=== Modus prüfen ===
<syntaxhighlight lang="bash" highlight="1" copy>
getenforce
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy>
touch /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
ls -Z /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="console" highlight="" line>
unconfined_u:object_r:user_tmp_t:s0 /tmp/testfile
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy>
setfattr -n security.selinux -v "system_u:object_r:shadow_t:s0" /tmp/testfile
</syntaxhighlight>

Zum Setzen von Attributen kann auch das Werkzeug chcon verwendet werden; in diesem Fall sieht der Befehl wie folgt aus
<syntaxhighlight lang="bash" highlight="1" copy>
chcon -t shadow_t /tmp/testfile
</syntaxhighlight>

Über das Werkzeug chcon sprechen wir etwas später noch genauer besprochen

Prüfung, ob die Attribute korrekt gesetzt wurden
<syntaxhighlight lang="console" highlight="1" copy>
sudo ls -Z /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="console" highlight="" line>
unconfined_u:object_r:shadow_t:s0 /tmp/testfile
</syntaxhighlight>

Schließlich muss nun ein Verstoß provoziert werden; dazu versuchen wir, die Datei zu lesen oder zu ändern
<syntaxhighlight lang="bash" highlight="1" copy>
echo "test" > /tmp/testfile
</syntaxhighlight>

Nun betrachten wir die AVC-Ereignisse mit dem Werkzeug ausearch
<syntaxhighlight lang="bash" highlight="1" copy>
ausearch -m AVC -ts recent
</syntaxhighlight>

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
<syntaxhighlight lang="console" highlight="1" copy>
sudo id -Z
</syntaxhighlight>
<syntaxhighlight lang="console" highlight="" line>
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy>
cp /usr/bin/cat /tmp/fake_httpd
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
setfattr -n security.selinux -v "system_u:object_r:httpd_t:s0" /tmp/fake_httpd sudo oder chcon -t httpd_t /tmp/fake_httpd
</syntaxhighlight>

Prüfung
<syntaxhighlight lang="bash" highlight="" copy>
systemd-run -p SELinuxContext=system_u:system_r:httpd_t:s0 /tmp/fake_httpd /tmp/testfile
</syntaxhighlight>
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
<syntaxhighlight lang="bash" highlight="1" copy>
ausearch -m AVC -ts recent -c fake_httpd
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="" line>
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
</syntaxhighlight>

* { 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
<syntaxhighlight lang="bash" highlight="1" line copy>
setfattr -n security.selinux -v "system_u:object_r:user_home_t:s0" /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
chmod 777 /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
systemd-run -p SELinuxContext=system_u:system_r:httpd_t:s0 /tmp/fake_httpd /tmp/testfile
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy>
ausearch -m AVC -ts recent -c fake_httpd
</syntaxhighlight>

Und erneut erscheint im Log eine Meldung über einen Verstoß
<syntaxhighlight lang="bash" highlight="" line>
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
</syntaxhighlight>

; 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" copy>
setenforce 1 && setenforce 0
</syntaxhighlight>

=== 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
<syntaxhighlight lang="bash" highlight="1" copy line>
mkdir -p /tmp/web_content/images
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
cd /tmp/web_content/
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
touch manual
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
touch test.conf
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
touch images/image.png
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Zd /tmp/web_content/
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z -1 /tmp/web_content/
</syntaxhighlight>

Diesem Verzeichnis wurde der Typ '''user_tmp_t''' vererbt, ebenso den darin enthaltenen Dateien

Versuchen wir, den vollständigen Kontext manuell zu setzen
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon system_u:object_r:httpd_sys_content_t:s0 manual
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z -1
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -t shadow_t manual
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -R -v -t httpd_sys_content_t /tmp/web_content
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z -1
</syntaxhighlight>

Um den Kontext von einem bereits korrekt gelabelten Objekt zu kopieren, kann die Option '''--reference=RFILE''' verwendet werden
<syntaxhighlight lang="bash" highlight="1" copy line>
touch /tmp/ref
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -R --reference=/tmp/ref /tmp/web_content
</syntaxhighlight>
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Z -1
</syntaxhighlight>

; Parameter für den Umgang mit Symlinks
{| class="wikitable sortable options gnu big"
|-
! 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
|}

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

# '''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
# '''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
# '''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
# '''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.''
# '''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
{| class="wikitable options big col1center"
! 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

# '''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
# '''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(/.*)?
# '''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

# '''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
# '''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
# '''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
{| class="wikitable big options"
!matchpathcon -m
!file_contexts
|-
|file
|--
|-
|dir
|-d
|-
|lnk_file
|-l
|-
|sock_file
|-s
|-
|pipe
|-p
|-
|chr_file
|-c
|-
|blk_file
|-b
|}
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

== Verwaltung von Kontexten mit semanage ==
Nun ist es endlich an der Zeit, die Verwaltung der File-Context-Datenbank zu betrachten

Wie bereits zuvor besprochen, überschreibt chcon direkt die erweiterten Attribute (xattr) auf dem Datenträger, teilt der SELinux-Policy-Datenbank (file_contexts) jedoch absolut nichts darüber mit

Änderungen, die mit chcon vorgenommen werden, sind im Maßstab des Systemlebenszyklus nur temporär

Sie werden bei jedem der folgenden Ereignisse unwiderruflich zerstört (durch Referenzwerte aus der Datenbank überschrieben)
* der Administrator startet das Dienstprogramm restorecon manuell für dieses Verzeichnis;
* es erfolgt ein Systemupdate eines Pakets (zum Beispiel des Webservers), dessen Installer eine Prüfung der Kontexte auslöst;
* beim Booten wird ein vollständiges Relabeling des Dateisystems initiiert (durch Erzeugen der Datei /.autorelabel)

=== semanage fcontext ===
Damit ein Kontext alle Updates und Relabeling-Vorgänge übersteht, muss man dem SELinux-System selbst beibringen, dass ein nicht standardmäßiger Pfad nun ein bestimmtes Label haben soll

Dafür wird das Werkzeug semanage (SELinux Policy Management Tool) verwendet
* Es ist das allgemeine Werkzeug zur lokalen Verwaltung von Elementen der SELinux-Policy, darunter: login mappings, SELinux users, ports, interfaces, modules, booleans, permissive types und file contexts
* Für den aktuellen Schritt ist insbesondere der Bereich fcontext relevant

==== Verwendung ====
Zur Demonstration versuchen wir, ein nicht standardmäßiges Verzeichnis mit hochsensiblen Daten zu schützen

Stellen wir uns folgende Situation vor: Entwickler haben ein internes Authentifizierungssystem ausgerollt, das Sicherungskopien der Passwort-Hashes von Benutzern in einem nicht standardmäßigen Verzeichnis speichert — /opt/app_auth/vault/
<syntaxhighlight lang="bash" highlight="" copy line>
mkdir -p /opt/app_auth/vault
ls -Zd /opt/app_auth/vault/
</syntaxhighlight>

Wenn wir uns an die Analyse der Datei file_contexts aus den vorherigen Schritten erinnern, erhalten das Verzeichnis /opt/ und sein gesamter Inhalt standardmäßig den Kontext usr_t

; Das ist ein öffentlicher Kontext
* '''Die meisten laufenden Dienste und Benutzer dürfen Dateien mit diesem Label lesen.'''
* '''Passwörter dort zu speichern ist unzulässig.'''
* Daher muss für dieses Verzeichnis eine grundlegende Regel erstellt werden

Verwenden wir dazu die Parameter -a (add) und -t (Feld type)
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -a -t shadow_t "/opt/app_auth/vault(/.*)?"
</syntaxhighlight>

"/opt/app_auth/vault(/.*)?" — ein regulärer Ausdruck, der das Verzeichnis selbst und absolut alle darin enthaltenen Dateien umfasst

Nun prüfen wir den Kontext des Verzeichnisses
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -Zd /opt/app_auth/vault/
</syntaxhighlight>
...und sehen, dass sich nichts geändert hat
* Das liegt daran, dass wir zwar einen Eintrag in die Datenbank hinzugefügt haben, das bloße Hinzufügen eines Eintrags jedoch kein Relabeling auslöst
* Um die Änderungen anzuwenden, wird das uns bereits bekannte Werkzeug restorecon verwendet
<syntaxhighlight lang="bash" highlight="" copy line>
restorecon -Rv /opt/app_auth/vault/
ls -Zd /opt/app_auth/vault/
</syntaxhighlight>

Ergebnis
<syntaxhighlight lang="bash" highlight="" copy line>
# ls -Zd /opt/app_auth/vault/
unconfined_u:object_r:shadow_t:s0 /opt/app_auth/vault/
</syntaxhighlight>

Prüfen wir, ob der Eintrag in der File-Context-Datenbank vorhanden ist
<syntaxhighlight lang="bash" highlight="" copy line>
cat /etc/selinux/default/contexts/files/file_contexts.local

# This file is auto-generated by libsemanage
# Do not edit directly

/opt/app_auth/vault(/.*)? system_u:object_r:shadow_t:s0
</syntaxhighlight>

'''Jetzt sind die vertraulichen Daten zuverlässig geschützt!'''

==== Optionen ====
Das Werkzeug semanage verfügt über verschiedene nützliche Optionen; konzentrieren wir uns auf die wichtigsten

Welche nicht standardmäßigen Regeln manuell hinzugefügt wurden, kann mit der Option -l (list) zusammen mit dem Modifikator -C (Custom) angezeigt werden
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -lC
</syntaxhighlight>

Den Kontexttyp für den bereits in der lokalen Datenbank registrierten Pfad /srv/myweb(/.*)? kann man mit der Option -m (modify) aktualisieren
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -m -t httpd_sys_rw_content_t "/srv/myweb(/.*)?"
</syntaxhighlight>

Wichtig ist, dass der reguläre Ausdruck genau mit dem Eintrag in der Datenbank übereinstimmt, dessen Kontext wir ändern wollen

Wenn ein Dienst außer Betrieb genommen wurde und das nicht standardmäßige Verzeichnis nicht mehr benötigt wird, kann die Regel mit der Option -d gelöscht werden
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -d "/opt/app_auth/vault(/.*)?"
</syntaxhighlight>

=== Äquivalente Pfade (Equivalence Rules) ===
Bei der Arbeit mit mehreren Verzeichnissen entsteht häufig die Situation, dass
* bereits eine korrekt gekennzeichnete Struktur existiert
* eine Kopie dieser Struktur an einem anderen Ort erstellt werden muss

==== Beispielaufgabe ====
Es gibt den Standardpfad des Webservers /var/www, wir haben jedoch beschlossen, die Dateien unserer neuen Website in einem nicht standardmäßigen Verzeichnis abzulegen, zum Beispiel auf einer separaten Festplatte, die unter /srv/myweb eingehängt ist

Wir erstellen zur Veranschaulichung mehrere Ordner im ursprünglichen Verzeichnis /var/www und bereiten das neue Verzeichnis /srv/myweb vor
<syntaxhighlight lang="bash" highlight="" copy line>
mkdir -p /var/www/sessions && mkdir -p /var/www/cgi-bin
restorecon -v -R /var/www
ls -Z1 /var/www
mkdir -p /srv/myweb
cp -r /var/www/* /srv/myweb/
ls -Z1 /srv/myweb
</syntaxhighlight>

Standardmäßig sind für das Verzeichnis /var/www und alle seine Unterverzeichnisse (html, cgi-bin usw.) im System bereits Dutzende komplexer regulärer Ausdrücke definiert, die die korrekten Kontexte zuweisen (zum Beispiel httpd_cache_t für /var/www/uploads(/.*)?)
* Alle regulären Ausdrücke aus /var/www manuell für das neue Verzeichnis /srv/myweb umzuschreiben, wäre aufwendig, unhandlich und fehleranfällig

Für die Lösung solcher Aufgaben werden Äquivalenzregeln verwendet (Parameter -e des Befehls semanage fcontext)
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage fcontext -a -e /var/www /srv/myweb
</syntaxhighlight>

Änderungen anwenden
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -v -R /srv/myweb
</syntaxhighlight>

Sehen wir uns an, wie das in der Datenbank aussieht
<syntaxhighlight lang="bash" highlight="" copy line>
# semanage fcontext -lC
SELinux fcontext type Context
/opt/app_auth/vault(/.*)? all files system_u:object_r:shadow_t:s0

SELinux Local fcontext Equivalence
/srv/myweb = /var/www
</syntaxhighlight>

Eine Äquivalenzregel funktioniert wie ein transparenter Alias: Wenn SELinux irgendeine Datei innerhalb von /srv/myweb/ prüft, ersetzt es in deren Pfad virtuell /srv/myweb durch /var/www und sucht erst danach Übereinstimmungen in seiner umfangreichen Datenbank regulärer Ausdrücke

Wenn es erforderlich ist, die Äquivalenzregel zu entfernen, geschieht dies mit dem bereits bekannten Parameter -d; man muss ihn lediglich anstelle des Parameters -a aus dem ursprünglichen Befehl verwenden
<syntaxhighlight lang="bash" highlight="" copy line>
semanage fcontext -d -e /var/www /srv/myweb
semanage fcontext -lC
</syntaxhighlight>

=== Export und Import lokaler Policies ===
Das Dienstprogramm semanage kann Policies mit den Befehlen semanage export und semanage import in eine Datei exportieren beziehungsweise aus einer Datei importieren
* In der Praxis wird das zum Beispiel verwendet, wenn ein Administrator plant, Policies von einem Testserver auf die Produktionsumgebung zu übertragen

==== Export ====
Verwendungsbeispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage export -f /tmp/selinux_local_rules.txt
</syntaxhighlight>

Prüfen wir, was sich darin befindet
<syntaxhighlight lang="bash" highlight="" copy line>
cat /tmp/selinux_local_rules.txt
boolean -D
login -D
interface -D
...
fcontext -a -f a -t shadow_t -r 's0' '/opt/app_auth/vault(/.*)?'
module -d acpi
module -d aisexec
module -d amtu
..
</syntaxhighlight>

Wie man sehen kann, ist die Datei logisch in drei Teile gegliedert

* '''Bereinigungsblock''' (Einträge mit dem Schlüssel -D) – beim Import der Datei auf einem neuen Server (über semanage import) soll das Policy-System zu einer ''exakten Kopie'' des Quellservers werden
* Daher müssen alle lokalen Einstellungen gelöscht werden
* Der Schlüssel -D wird als Delete interpretiert
* '''Lokale Regeln''' (im Beispiel die einzige Regel fcontext)
* '''Block deaktivierter Policy-Module''' (Einträge mit dem Schlüssel -d) – das Policy-Set default policy in Debian ist gehärtet (hardened) und deaktiviert ungenutzte Module
* In RHEL macht die Policy targeted genau das Gegenteil: Dort sind standardmäßig von Anfang an alle Module aktiviert, unabhängig davon, ob die entsprechende Software installiert ist oder nicht

==== Import ====
Für den Import wird der Befehl semanage import verwendet; seine Syntax sieht identisch zum Export aus
<syntaxhighlight lang="bash" highlight="1" copy line>
semanage import -f /tmp/selinux_local_rules.txt
</syntaxhighlight>

Wenn uns die importierten Policies zusagen und alles Erforderliche mit matchpathcon -V geprüft wurde, wenden wir die Änderungen an
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -Rv /
</syntaxhighlight>

[[Kategorie:Linux/SELinux/Praxis]]

= RHEL =
=== 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
<syntaxhighlight lang="bash" highlight="" copy line>
ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
</syntaxhighlight>

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

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‘' '' aus, 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
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -t httpd_sys_content_t ‚'file-name‘'
</syntaxhighlight>

* Führen Sie den Befehl ''chcon -R -t ‚'type‘' ‚'directory-name‘''' aus, um den Typ des Verzeichnisses und dessen Inhalt zu ändern, wobei ‚'type‘' ein SELinux-Typ ist, wie beispielsweise ''httpd_sys_content_t'', und ‚'Verzeichnisname‘' ein Verzeichnisname ist
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -R -t httpd_sys_content_t ‚'Verzeichnisname‘'
</syntaxhighlight>

; Ä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
# Erstellen Sie eine neue Datei und zeigen Sie deren SELinux-Kontext an
<syntaxhighlight lang="bash" highlight="" copy line>
touch file1

ls -Z file1
-rw -rw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
</syntaxhighlight>

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‘'
# 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
<syntaxhighlight lang="bash" highlight="" copy line>
chcon -t samba_share_t file1

ls -Z file1
-rw-rw-r-- user1 group1 unconfined_u:object_r:samba_share_t:s0 file1
</syntaxhighlight>

# Verwenden Sie den folgenden Befehl, um den SELinux-Kontext für die Datei ''file1'' wiederherzustellen
* Verwenden Sie die Option ''-v'', um die Änderungen anzuzeigen
<syntaxhighlight lang="bash" highlight="" copy line>
restorecon -v file1
restorecon reset file1 context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:user_home_t:s0
</syntaxhighlight>

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

# Geben Sie als root den folgenden Befehl ein, um den Typ des Verzeichnisses ''web/'' (und dessen Inhalt) in ''httpd_sys_content_t'' zu ändern
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

# Um die Standard-SELinux-Kontexte wiederherzustellen, verwenden Sie das Dienstprogramm ''restorecon'' als root
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -C -l
</syntaxhighlight>

Ä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
# Geben Sie den folgenden Befehl ein und achten Sie darauf, den vollständigen Pfad zur Datei oder zum Verzeichnis zu verwenden
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -a ‚'Optionen‘' ‚'Dateiname‘ ‚|‘'Verzeichnisname'‚
</syntaxhighlight>

# Verwenden Sie das Dienstprogramm ''restorecon'', um die Kontextänderungen anzuwenden
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo restorecon -v ‘'Dateiname'‚|‘'Verzeichnisname'‚
</syntaxhighlight>

===== 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
<syntaxhighlight lang="bash" highlight="" copy line>
sudo touch /etc/file1

ls -Z /etc/file1
-rw-r--r-- root root unconfined_u:object_r:etc_t:s0 /etc/file1
</syntaxhighlight>

Um Informationen zu einem Verzeichnis aufzulisten, verwenden Sie den folgenden Befehl
<syntaxhighlight lang="bash" highlight="1" copy line>
ls -dZ ‚'Verzeichnisname‘'
</syntaxhighlight>

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

# Verwenden Sie als root das Dienstprogramm ''restorecon'', um den Typ zu ändern
* Da ''semanage'' einen Eintrag für ''/etc/file1'' in ''file_contexts.local'' hinzugefügt hat, ändert ''restorecon'' den Typ in ''samba_share_t''
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

; Ä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
# 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
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

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

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
<syntaxhighlight lang="bash" highlight="1" copy line>
/web(/.*)? system_u:object_r:httpd_sys_content_t:s0
</syntaxhighlight>

# Verwenden Sie als root das Dienstprogramm ''restorecon'', um den Typ von ''web/'' sowie aller darin enthaltenen Dateien zu ändern
* Der Parameter ''-R'' steht für rekursiv, was bedeutet, dass alle Dateien und Verzeichnisse unter ''web/'' mit dem Typ ''httpd_sys_content_t'' gekennzeichnet werden
* Da ''semanage'' einen Eintrag für ''/web(/.*)?'' in ''file.contexts.local'' hinzugefügt hat, ändert ''restorecon'' die Typen in ''httpd_sys_content_t''
<syntaxhighlight lang="bash" highlight="" copy line>
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
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -d „/web(/.*)?“
</syntaxhighlight>

# Um den Kontext zu entfernen, geben Sie als Root den folgenden Befehl ein, wobei ‚'Dateiname‘'|‚'Verzeichnisname‘' der erste Teil in ''file_contexts.local'' ist
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -d ‚'Dateiname‘'|‚'Verzeichnisname‘'
</syntaxhighlight>

Das Folgende ist ein Beispiel für einen Kontext in ''file_contexts. local''
<syntaxhighlight lang="bash" highlight="1" copy line>
/test system_u:object_r:httpd_sys_content_t:s0
</syntaxhighlight>

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
<syntaxhighlight lang="bash" highlight="1" copy line>
sudo semanage fcontext -d /test
</syntaxhighlight>

# 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
* Basierend auf der Systemrichtlinie generiert ''semanage'' die Dateien ''file_contexts.homedirs'' und ''file_contexts''-Dateien

Systemadministratoren können Dateikontextdefinitionen mit dem Befehl ''semanage fcontext'' anpassen
* Solche Anpassungen werden in der Datei ''file_contexts.local'' gespeichert

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“
* das Ändern und Hinzufügen einer Dateikontextdefinition durch eine Systemrichtlinienoperation, siehe Abschnitt „''Pflege von SELinux-Labels''“ oder Abschnitt „''Priorisierung und Deaktivierung von SELinux-Richtlinienmodulen''“

[[Kategorie:Linux/SELinux/04]]

Linux/SELinux/04/09 Dateisysteme

2026-03-29T14:26:23Z

DanielZorin: /* Verwaltung von Kontexten mit semanage */

= Debian =
=== Mount-Optionen ===
==== context (Globale Überschreibung) ====
Die Option context= ist in zwei Hauptfällen nützlich
* das Dateisystem '''unterstützt keine''' xattr, sodass ein normales SELinux-Labeling darauf nicht möglich ist;
* dem Dateisystem '''kann im Hinblick auf bereits vorhandene Attribute nicht vertraut werden''', und beim Mounten muss vorübergehend ein einheitlicher sicherer Kontext erzwungen werden
** Ein praktisches Beispiel sind Wechselmedien (USB-Sticks)

Wenn context= gesetzt ist, versucht SELinux nicht mehr, xattr vom Datenträger zu lesen
* Auch die Datenbank file_contexts wird für diesen Pfad ignoriert
* Es ist dann nicht möglich, das Label einer einzelnen Datei innerhalb einer solchen Ressource mit chcon oder restorecon zu ändern — der Kernel gibt in diesem Fall einen Fehler zurück

; Befehlsbeispiele
Für Wechselmedien
<syntaxhighlight lang="bash" highlight="1" copy line>
mount -o context="system_u:object_r:removable_t:s0" /dev/sdb1 /mnt/usb
</syntaxhighlight>

Für eine Netzwerkressource, die vom Webserver gelesen werden soll
<syntaxhighlight lang="bash" highlight="1" copy line>
mount server:/export /srv/www -o context="system_u:object_r:httpd_sys_content_t:s0"
</syntaxhighlight>

==== defcontext= (Standardkontext) ====
Die Option defcontext= dient einer anderen Aufgabe: Sie '''ändert den Kontext für unlabeled Dateien'''

Sie wirkt nur dort, wo ein Objekt '''kein eigenes SELinux-Label auf dem Datenträger''' hat
* Wenn eine Datei bereits ein Label hat, verwendet SELinux dieses
* Wenn kein Label vorhanden ist (zum Beispiel wenn eine Datei gerade aus einem alten System ohne SELinux-Unterstützung kopiert wurde), wird ihr „on the fly“ der in defcontext= angegebene Kontext zugewiesen

; Befehlsbeispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
mount /dev/sdb2 /test -o defcontext="system_u:object_r:samba_share_t:s0"
</syntaxhighlight>

==== rootcontext= (Kontext des Mount-Punkts) ====
Die Option rootcontext= erlaubt es, den Kontext des '''Root-Inodes''' eines Dateisystems explizit festzulegen, '''bevor es im Userspace sichtbar wird'''
* Sie bestimmt den Kontext ausschließlich für das '''Wurzelverzeichnis''' des eingehängten Dateisystems, ohne dessen Inhalt zu beeinflussen

Das ist nützlich, wenn das korrekte Label für das Verzeichnis selbst (zum Beispiel /mnt/backup) gesetzt werden soll, damit Dienste es betreten können, während die individuellen Labels aller enthaltenen Dateien auf dem Datenträger erhalten bleiben
<syntaxhighlight lang="bash" highlight="1" copy line>
mount -t tmpfs none /srv/chroot -o rootcontext="system_u:object_r:tmp_t:s0"
</syntaxhighlight>

==== fscontext= (Kontext des Superblocks) ====
Weist der abstrakten Dateisysteminstanz selbst einen Kontext als Objekt zu, nicht den darin enthaltenen Dateien

Dies ist eine Low-Level-Option
* Sie wird von SELinux selbst verwendet, um zu bestimmen, ob ein bestimmter Prozess (zum Beispiel ein Mount-Daemon) das Recht hat, Dateisysteme dieses Typs einzuhängen
* In der täglichen Administration wird sie manuell nur äußerst selten verwendet

=== Aufgabe ===
Wir erstellen zwei Mount-Punkte
<syntaxhighlight lang="bash" highlight="" copy line>
sudo mkdir -p /mnt/lab_context
sudo mkdir -p /mnt/lab_rootcontext
</syntaxhighlight>

Wir mounten tmpfs mit einem einheitlichen Kontext
<syntaxhighlight lang="bash" highlight="" copy line>
sudo mount -t tmpfs none /mnt/lab_context -o context="system_u:object_r:httpd_sys_content_t:s0"
ls -Zd /mnt/lab_context
</syntaxhighlight>

Nun erstellen wir einige Objekte darin
<syntaxhighlight lang="bash" highlight="" copy line>
touch /mnt/lab_context/file1
mkdir /mnt/lab_context/dir1
ls -lZ1 /mnt/lab_context
</syntaxhighlight>

Jetzt versuchen wir, den Kontext manuell zu ändern
<syntaxhighlight lang="bash" highlight="1" copy line>
chcon -t tmp_t /mnt/lab_context/file1
</syntaxhighlight>

'''Der Kernel gibt einen Fehler zurück, da bei Verwendung des Mount-Parameters''' context= '''eine Kontextänderung nicht möglich ist.'''

Nun versuchen wir, ein anderes Dateisystem mit dem Parameter defcontext= einzuhängen
<syntaxhighlight lang="bash" highlight="" copy line>
mount -t tmpfs none /mnt/lab_rootcontext -o rootcontext="system_u:object_r:samba_share_t:s0"
ls -Zd /mnt/lab_rootcontext
</syntaxhighlight>

Wir erstellen Objekte
<syntaxhighlight lang="bash" highlight="" copy line>
touch /mnt/lab_rootcontext/file1
mkdir /mnt/lab_rootcontext/dir1
touch /mnt/lab_rootcontext/file2
ls -lZ1 /mnt/lab_rootcontext
</syntaxhighlight>

Wie man sehen kann, wurde der Kontext der Dateien vom root-Verzeichnis geerbt

Nun versuchen wir, den Kontext zu ändern
<syntaxhighlight lang="bash" highlight="" copy line>
chcon -R -t tmp_t /mnt/lab_rootcontext/*
ls -lZ1 /mnt/lab_rootcontext/
</syntaxhighlight>

'''Und der Vorgang wird erfolgreich ausgeführt, da''' rootcontext '''nur den Kontext des Wurzelverzeichnisses des eingehängten Dateisystems ändert.'''

Das kann nützlich sein, wenn ein temporärer Speicher auf tmpfs benötigt wird, dessen Wurzel jedoch sofort den richtigen Typ haben soll, damit neue Dateien den gewünschten Kontext erben
* Gleichzeitig bleibt die Möglichkeit erhalten, andere Dateien mit bereits vorhandenem, vom Wurzelverzeichnis abweichendem Kontext zu schreiben

== Wiederherstellung korrekter Labels ==
; Relabeling mit restorecon

Der Arbeitsablauf von restorecon lässt sich vereinfacht wie folgt beschreiben
# Das Werkzeug übernimmt einen Zielpfad und liest die aktive SELinux-Policy bzw. die zugehörige File-Context-Datenbasis
# Der Zielpfad wird gegen die regulären Ausdrücke aus der Policy-Datenbasis abgeglichen
# Das Werkzeug liest den tatsächlich gesetzten erweiterten Dateiattributwert (xattr) des Objekts direkt aus dem Dateisystem
# Anschließend erfolgt ein Vergleich zwischen dem laut Policy erwarteten Kontext und dem tatsächlich gesetzten Label (Attribut) des Objekts
# Falls die Prüfung rekursiv für ein Verzeichnis ausgeführt wurde, berechnet restorecon einen Hash über die dabei verwendeten regulären Ausdrücke und speichert ihn im versteckten Attribut des Verzeichnisses security.sehash
#* Beim nächsten Lauf beginnt Schritt 2 dann mit dem Vergleich dieses Hashes, um Zeit zu sparen

==== Verwendung ====
In der Praxis werden drei Betriebsarten verwendet

; Passive Prüfung ohne Änderungen
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -nv /var/www/html/index.html
</syntaxhighlight>

Die Option -n verhindert das Schreiben neuer Labels und versetzt das Werkzeug in den Prüfmodus
* Der Parameter -v zeigt Objekte an, deren Labels vom erwarteten Zustand abweichen

; Korrektur eines einzelnen Objekts
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -v /var/www/html/index.html
</syntaxhighlight>

Korrigiert den Kontext der angegebenen Datei
* Praktisch werden dabei genau die Änderungen angewendet, die im vorherigen Beispiel lediglich angezeigt wurden

; Massenhafte rekursive Korrektur eines Verzeichnisbaums
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -Rv /var
</syntaxhighlight>

Die Optionen -R und -r aktivieren den rekursiven Verzeichnisdurchlauf
* Genau dieser Modus wird typischerweise nach dem Hinzufügen neuer Regeln mit semanage fcontext oder nach einer beschädigten Teil-Relabeling-Situation verwendet

=== customizable types ===
In SELinux existiert ein Ausnahme-Mechanismus für Relabeling mit der Bezeichnung customizable types

Dabei handelt es sich um eine vordefinierte Liste von Kontexten (Typen), die vom System als manuell administrierbar betrachtet werden
* Entsprechend werden solche Dateien bei der Prüfung und beim Relabeling durch SELinux-Werkzeuge und -Mechanismen (einschließlich restorecon, .autorelabel, setfiles, fixfiles) ignoriert

Die Liste der customizable types wird aus folgender Datei gelesen
<syntaxhighlight lang="bash" highlight="1" copy line>
/etc/selinux/{SELINUXPOLICY}/contexts/customizable_types
</syntaxhighlight>

Obwohl der Mechanismus der customizable types in modernen Distributionen weiterhin existiert und funktioniert, gilt er in der Administratoren-Community heute als '''veraltender Ansatz'''
* Der Grund ist, dass die Datei lediglich Informationen darüber enthält, welche Typen ignoriert werden, nicht jedoch, welchen konkreten Dateien diese Typen zugewiesen wurden
* In einer Störungssituation kann diese Information unwiederbringlich verloren gehen
* Die File-Context-Datenbank enthält dagegen alle erforderlichen Informationen, um den gewünschten Label-Zustand im Dateisystem reproduzierbar wiederherzustellen

Um Dateien mit customizable types dennoch zwangsweise auf den vollständig erwarteten Kontext zurückzusetzen, muss restorecon mit dem Parameter -F (Force) ausgeführt werden
* In diesem Fall werden '''alle Felder des Kontexts wiederhergestellt'''
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -F -v /srv/custom_app
</syntaxhighlight>

=== Beschleunigung durch Digest-Prüfung ===
; Das Werkzeug restorecon_xattr
Beim rekursiven Relabeling mit restorecon -D durchläuft das Werkzeug den Verzeichnisbaum nicht nur und korrigiert Kontexte, sondern '''schreibt zusätzlich einen internen Digest in das xattr des Verzeichnisses'''.

; Digest wird im erweiterten Attribut ''security.sehash'' gespeichert

Die Aufgabe dieses Digests besteht darin festzuhalten, dass dieses Verzeichnis bereits gegen einen bestimmten Satz von file_contexts-Dateien geprüft wurde, die für die Zuordnung von Pfaden zu erwarteten Kontexten verwendet werden
* Beim nächsten Lauf von restorecon -D wird dieser Hash zur Prüfung herangezogen und bei Bedarf aktualisiert, falls er veraltet ist
In modernen RHEL-Versionen wird zur Berechnung dieses Werts '''der kryptographische Algorithmus SHA-256''' verwendet (in älteren Systemen kam SHA-1 zum Einsatz).
'''Red Hat/Fedora''' verwenden seit RHEL 9 bzw. Fedora 34+ beim Paket-Build einen eigenen Patch für den Quellcode
* In den Paketquellen findet sich dazu direkt eine Datei mit dem Namen 0001-Use-SHA-2-instead-of-SHA-1.patch

Debian verwendet weiterhin SHA-1
* Das ist in diesem Kontext jedoch unkritisch, da der Hash im Verzeichnis-xattr nicht für Sicherheitsfunktionen oder Verschlüsselung verwendet wird

==== restorecon_xattr ====
Für die Arbeit mit diesen internen Digest-Einträgen (Anzeigen/Bereinigen) stehen folgende Kommandos zur Verfügung
* restorecon -D (Hashes erzeugen / Dateien unter Verwendung vorhandener Hashes prüfen)
* restorecon -I (Hashes erzeugen / neu erzeugen, wobei vorhandene ignoriert werden)
* sowie das separate Werkzeug restorecon_xattr (Hashes anzeigen / löschen)

; Funktionen von restorecon_xattr
* '''Verzeichnisse anzeigen''', in denen security.sehash vorhanden ist
* '''Digest und dessen Status''' im Vergleich zum aktuellen Policy-Satz anzeigen
* '''nur veraltete Digest-Einträge löschen'''
* '''alle Digest-Einträge''' in einem angegebenen Verzeichnisbaum löschen

; Praxisbeispiel mit einigen Hashes
Start von restorecon mit dem Flag -D und rekursivem Modus -R
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -RDv /var/log
</syntaxhighlight>

Anzeige des Ergebnisses mit restorecon_xattr (zusätzlich mit -r für rekursive Ausgabe)
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon_xattr -r /var/log
</syntaxhighlight>

Zum Entfernen von Hashes, die nicht mehr zum aktuellen Policy-Satz passen, wird der Parameter -d verwendet

Das Werkzeug berechnet einen neuen Hash und entfernt den alten Hash bei Nichtübereinstimmung (neue Hashes werden dabei nicht geschrieben)
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon_xattr -d -r /var/www
</syntaxhighlight>

Vollständiges Entfernen aller Digests
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon_xattr -D -r /var/www
</syntaxhighlight>

Dabei werden alle security.sehash-Einträge aus dem Verzeichnisbaum entfernt, unabhängig davon, ob sie noch aktuell sind oder nicht
* Der nächste Lauf von restorecon -D muss die Digests anschließend vollständig neu erzeugen

Wichtig ist, dass sich der Nutzen von restorecon -D erst bei '''rekursiver Verarbeitung''' (-R / -r) entfaltet
* Nach einem erfolgreichen rekursiven Relabeling wird beim erneuten Ausführen von restorecon -D (mit denselben Parametern und demselben Policy-Satz) der gespeicherte Digest zur Beschleunigung des Verzeichnisdurchlaufs verwendet
* Das ist insbesondere bei der Prüfung großer Verzeichnisbäume oder sogar des gesamten Dateisystems ab / nützlich

Das bedeutet: '''Wenn der Parameter''' -D '''gesetzt ist''', wird für '''Verzeichnisse ohne vorhandenen Hash''' ein neuer Digest berechnet und in den Attributen gespeichert
* Falls '''für ein Verzeichnis bereits ein Hash existiert''', prüft restorecon dessen Gültigkeit, indem es ihn mit dem neu aus der File-Context-Datenbank berechneten Wert vergleicht. '''Bei Übereinstimmung wird das Verzeichnis beschleunigt verarbeitet.''' '''Bei Nichtübereinstimmung erfolgt die Prüfung des aktuellen Verzeichnisses und aller Unterverzeichnisse im normalen Modus''', also so, als wäre -D nicht gesetzt

Wird der Parameter -D nicht verwendet, nutzt restorecon den Mechanismus security.sehash bei der Prüfung überhaupt nicht

Wird restorecon -I verwendet, wird ein bereits gespeicherter Digest ignoriert
* Selbst wenn security.sehash formal übereinstimmt, vertraut restorecon diesem Eintrag nicht und '''führt im rekursiven Modus zwangsweise eine erneute vollständige Label-Prüfung durch; anschließend wird der Digest aktualisiert'''
* Voraussetzung ist, dass das Flag -n nicht gesetzt ist und während der Ausführung keine Fehler auftreten

; Anwendungsbeispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
restorecon -RIv /var/log
</syntaxhighlight>

Das Verzeichnis wird rekursiv geprüft, und jeder Hash wird unabhängig davon, ob bereits ein Digest in den Attributen vorhanden ist, neu erzeugt

== Relabeling-Werkzeuge ==
; Die Werkzeuge für Relabeling lassen sich in drei Ebenen unterteilen

* setfiles
** Das grundlegende, low-level ausführbare Binärprogramm (in C geschrieben)
** Es bildet den Kernmechanismus zur Anwendung der Policy
** restorecon arbeitet auf Basis von setfiles
* restorecon
** Ein Werkzeug auf Benutzerebene, das für gezielte administrative Eingriffe vorgesehen ist
** restorecon findet, lädt und verwendet automatisch die '''aktuell aktive SELinux-Policy'''
** Das Werkzeug restorecon wird durch dieselbe ausführbare Datei implementiert wie setfiles
** Der Betriebsmodus wird über argv[0] gewählt, also über den Namen, unter dem das Programm aufgerufen wird
* fixfiles
** Dabei handelt es sich nicht um eine Binärdatei, sondern um ein Shell-Skript, das den Aufruf von setfiles und restorecon für globale Systemaufgaben automatisiert
** Es ist eine skriptbasierte Wrapper-Schicht für typische Wartungsoperationen wie check, verify, restore, relabel, onboot sowie für paketbezogene und inkrementelle Betriebsarten
** Das Werkzeug kann mit der Datenbank des Paketmanagers (RPM) arbeiten
** So kann es beispielsweise alle Dateien ermitteln, die zu einem bestimmten Paket gehören, und ausschließlich diese neu labeln
** Außerdem steuert es den Ablauf eines vollständigen System-Relabelings beim Booten

=== Betriebsarten von fixfiles ===
==== fixfiles check / fixfiles verify ====
check und verify sind Betriebsarten ohne Änderung der Labels
* Sie geben alle inkorrekten Labels aus und zeigen dabei den alten sowie den neuen Kontext an, schreiben jedoch nichts zurück
* Das ist ein praktischer administrativer Audit-Modus vor einem Relabeling oder nach Änderungen an den Regeln

; Beispiel
<syntaxhighlight lang="bash" highlight="" copy line>
chcon -R -t tmp_t /var/www
chcon -R -t shadow_t /srv
fixfiles check /var/www /srv
</syntaxhighlight>

==== fixfiles restore ====
restore stellt inkorrekte Labels wieder her

; Beispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
fixfiles restore /var/www /srv/app
</syntaxhighlight>

==== fixfiles relabel ====
relabel ist für ein vollständiges Relabeling des gesamten Dateisystems vorgesehen
* Das Werkzeug schlägt vor, den Inhalt von /tmp zu löschen
* Anschließend werden alle inkorrekten Dateilabels so korrigiert, dass sie den installierten file_contexts entsprechen

; Beispiel
<syntaxhighlight lang="bash" highlight="1" copy line>
fixfiles relabel
</syntaxhighlight>

==== fixfiles onboot ====
onboot führt das Relabeling nicht sofort aus, sondern bereitet das System so vor, dass das Relabeling beim nächsten Systemstart erfolgt
<syntaxhighlight lang="bash" highlight="1" copy line>
fixfiles onboot
</syntaxhighlight>

=== Optionen ===
; Wichtige Optionen
{| class="wikitable options big"
|-
! Unix !! Beschreibung
|-
| -F || (Force) Setzt den Kontext auch bei Dateien mit customizable types zwangsweise zurück
|-
| -f || (force clear) Leert die temporären Verzeichnisse /tmp und /var/tmp automatisch vor Beginn der Ausführung, ohne interaktive Rückfragen
* Das ist besonders nützlich für Automatisierungsskripte
|-
| -C PREVIOUS_FILECONTEXT || (Compare) Vergleicht einen alten file_contexts-Stand mit dem aktuellen und stellt Kontexte nur dort wieder her, wo dies erforderlich ist
|-
| -N "YYYY-MM-DD HH:MM" || (Newer) Beschränkt die Verarbeitung auf Dateien, die nach dem angegebenen Zeitpunkt erstellt wurden
|-
| -B || Im Modus restore werden nur Dateien berücksichtigt, die heute verändert wurden
* Im Modus onboot schreibt derselbe Schalter das aktuelle Datum in /.autorelabel, wodurch das Relabeling beschleunigt werden kann
|-
| -M || (Mounts) Führt vor dem Relabeling Bind-Mounts für Dateisysteme aus, sodass auch Kontexte von Objekten korrekt repariert werden können, über denen etwas eingehängt ist
|-
| -T nthreads || (Threads) Konfiguriert die parallele Verarbeitung mit mehreren Threads oder deaktiviert diese bei -T 1
|-
| -l LOGPATH || (Log) Leitet die gesamte Ausgabe, also sowohl Standardausgabe als auch Fehlermeldungen, in die angegebene Logdatei statt auf den Bildschirm um
|}

== RHEL ==

=== Einbinden von Dateisystemen ===
Standardmäßig wird beim Einbinden eines Dateisystems, das erweiterte Attribute unterstützt, der Sicherheitskontext für jede Datei aus dem ‚'security.selinux‘'

erweiterten Attribut der Datei
* Dateien in Dateisystemen, die keine erweiterten Attribute unterstützen, wird ein einziger Standard-Sicherheitskontext aus der Richtlinienkonfiguration zugewiesen, basierend auf dem Dateisystemtyp

Verwenden Sie den Befehl [[mount -o context]], um vorhandene erweiterte Attribute zu überschreiben oder einen anderen Standardkontext für Dateisysteme festzulegen, die keine erweiterten Attribute unterstützen
* Dies ist nützlich, wenn Sie nicht darauf vertrauen, dass ein Dateisystem die richtigen Attribute bereitstellt, beispielsweise bei Wechselmedien, die in mehreren Systemen verwendet werden
* Der Befehl [[mount -o context]] kann auch verwendet werden, um die Kennzeichnung für Dateisysteme zu unterstützen, die keine erweiterten Attribute unterstützen, wie z. B. File Allocation Table (FAT) oder NFS-Volumes
* Der mit der Option [[context]] angegebene Kontext wird nicht auf die Festplatte geschrieben
die ursprünglichen Kontexte bleiben erhalten und sind beim Einbinden ohne [[context]] sichtbar, sofern das Dateisystem ursprünglich über erweiterte Attribute verfügte

Weitere Informationen zur Dateisystem-Kennzeichnung finden Sie in James Morris' Artikel „Filesystem Labeling in SELinux“
http://www.linuxjournal.com/article/7426

==== Kontext-Mounts ====
Um ein Dateisystem mit dem angegebenen Kontext zu mounten – wobei vorhandene Kontexte überschrieben werden, falls vorhanden – oder um einen anderen Standardkontext für ein Dateisystem festzulegen, das keine erweiterten Attribute unterstützt, verwenden Sie als Root-Benutzer den [[mount -o context=‚'SELinux_user:role:type:level‘']] beim Einhängen des gewünschten Dateisystems
* Kontextänderungen werden nicht auf die Festplatte geschrieben
* Standardmäßig werden NFS-Einhängungen auf der Client-Seite mit einem Standardkontext gekennzeichnet, der durch die Richtlinie für NFS-Volumes definiert ist
* In gängigen Richtlinien verwendet dieser Standardkontext den Typ [[nfs_t]]
* Ohne zusätzliche Mount-Optionen kann dies die Freigabe von NFS-Volumes über andere Dienste, wie den Apache-HTTP-Server, verhindern
* Das folgende Beispiel mountet ein NFS-Volume so, dass es über den Apache-HTTP-Server freigegeben werden kann
sudo mount server:/export /local/mount/point -o \ context="system_u:object_r:httpd_sys_content_t:s0"

Neu erstellte Dateien und Verzeichnisse auf diesem Dateisystem scheinen den mit [[-o context]] angegebenen SELinux-Kontext zu haben
* Da diese Änderungen jedoch nicht auf die Festplatte geschrieben werden, bleibt der mit dieser Option angegebene Kontext zwischen den Mountvorgängen nicht erhalten
* Daher muss diese Option bei jedem Mountvorgang mit demselben Kontext verwendet werden, um den erforderlichen Kontext beizubehalten
* Informationen dazu, wie man Kontext-Mounts dauerhaft macht, finden Sie im Abschnitt „Kontext-Mounts dauerhaft machen“

Die Typen-Durchsetzung ist die wichtigste Berechtigungssteuerung, die in der SELinux-Targeted-Policy verwendet wird
* In den meisten Fällen können SELinux-Benutzer und -Rollen ignoriert werden. Verwenden Sie daher beim Überschreiben des SELinux-Kontexts mit [[-o context]] den SELinux-Benutzer [[system_u]] und die Rolle [[object_r]] und konzentrieren Sie sich auf den Typ
* Wenn Sie nicht die MLS-Policy oder die Multi-Kategorie-Sicherheit verwenden, verwenden Sie die [[s0]]-Ebene

; Hinweis

Wenn ein Dateisystem mit einer [[context]]-Option eingebunden wird, sind Kontextänderungen durch Benutzer und Prozesse untersagt
* Wenn Sie beispielsweise den Befehl [[chcon]] auf einem mit einer [[context]]-Option eingebundenen Dateisystem ausführen, führt dies zu einem Fehler [[Operation not supported]]

==== Ändern des Standardkontexts ====
Wie in Abschnitt 4.8, „Die Typen file_t und default_t“ , wird auf Dateisystemen, die erweiterte Attribute unterstützen, beim Zugriff auf eine Datei, der auf der Festplatte ein SELinux-Kontext fehlt, so behandelt, als hätte sie einen Standardkontext, wie er durch die SELinux-Richtlinie definiert ist
* In gängigen Richtlinien verwendet dieser Standardkontext den Typ [[file_t]]
* Wenn ein anderer Standardkontext verwendet werden soll, mounten Sie das Dateisystem mit der Option [[defcontext]]

Das folgende Beispiel mountet ein neu erstelltes Dateisystem auf [[/
dev/sda2]] in das neu erstellte Verzeichnis [[test/]] ein
* Dabei wird davon ausgegangen, dass es in [[/etc/selinux/targeted/contexts/files/]] keine Regeln gibt, die einen Kontext für das Verzeichnis [[test/]] definieren
sudo mount /dev/sda2 /test/ -o defcontext="system_u:object_r:samba_share_t:s0"

In diesem Beispiel
* definiert die Option [[defcontext]], dass [[system_u:object_r:samba_share_t:s0]] „der Standard-Sicherheitskontext für nicht gekennzeichnete Dateien“ ist[5]
* wird das Stammverzeichnis ([[test/]]) des Dateisystems nach dem Einbinden so behandelt, als wäre es mit dem durch [[defcontext]] angegebenen Kontext gekennzeichnet (diese Kennzeichnung wird nicht auf der Festplatte gespeichert)
* Dies wirkt sich auf die Kennzeichnung von Dateien aus, die unter [[test/]] erstellt werden
neue Dateien erben den Typ [[samba_share_t]], und diese Kennzeichnungen werden auf der Festplatte gespeichert
* Dateien, die unter [[test/]] erstellt wurden, während das Dateisystem mit der Option [[defcontext]] eingebunden war, behalten ihre Kennzeichnungen

==== Einbinden eines NFS-Volumes ====
Standardmäßig werden NFS-Einbindungen auf der Client-Seite mit einem Standardkontext gekennzeichnet, der durch die Richtlinie für NFS-Volumes definiert ist
* In gängigen Richtlinien verwendet dieser Standardkontext den Typ [[nfs_t]]
* Je nach Richtlinienkonfiguration können Dienste wie der Apache-HTTP-Server und MariaDB möglicherweise keine Dateien lesen, die mit dem Typ [[nfs_t]] gekennzeichnet sind
* Dies kann verhindern, dass Dateisysteme, die mit diesem Typ gekennzeichnet sind, eingebunden und anschließend von anderen Diensten gelesen oder exportiert werden

Wenn Sie ein NFS-Volume mounten und dieses Dateisystem mit einem anderen Dienst lesen oder exportieren möchten, verwenden Sie beim Mounten die Option [[context]], um den Typ [[nfs_t]] zu überschreiben
* Verwenden Sie die folgende context-Option, um NFS-Volumes so einzuhängen, dass sie über den Apache-HTTP-Server freigegeben werden können
sudo mount server:/export /local/mount/point -o context="system_u:object_r:httpd_sys_content_t:s0"

Da diese Änderungen nicht auf die Festplatte geschrieben werden, bleibt der mit dieser Option angegebene Kontext zwischen den Einhängevorgängen nicht erhalten
* Daher muss diese Option bei jedem Einbinden mit demselben Kontext verwendet werden, um den erforderlichen Kontext beizubehalten
* Informationen dazu, wie Kontext-Mounts dauerhaft gemacht werden können, finden Sie im Abschnitt „Kontext-Mounts dauerhaft machen“

Als Alternative zum Einbinden von Dateisystemen mit [[context]]-Optionen können Boolesche Werte aktiviert werden, um Diensten den Zugriff auf Dateisysteme zu ermöglichen, die mit dem Typ [ [nfs_t]] gekennzeichnet sind
* Siehe Teil II, „Verwaltung eingeschränkter Dienste“ für Anweisungen zur Konfiguration von Booleans, um Diensten den Zugriff auf den Typ [[nfs_t]] zu ermöglichen

==== Mehrere NFS-Mounts ====
Wenn mehrere Mounts aus demselben NFS-Export durchgeführt werden und versucht wird, den SELinux-Kontext jedes Mounts durch einen anderen Kontext zu überschreiben, führen nachfolgende Mount-Befehle zu Fehlern
* Im folgenden Beispiel verfügt der NFS-Server über einen einzigen Export, [[export/]], der zwei Unterverzeichnisse enthält: [ [web/]] und [[database/]]
* Die folgenden Befehle versuchen zwei Mounts von einem einzigen NFS-Export und versuchen, den Kontext für jeden einzelnen zu überschreiben
sudo mount server:/export/web /local/web -o context="system_u:object_r:httpd_sys_content_t:s0"
sudo mount server:/export/database /local/database -o context="system_u:object_r:mysqld_db_t:s0"

Der zweite Mount-Befehl schlägt fehl, und Folgendes wird in [[/var/log/messages]] protokolliert
kernel
SELinux
mount invalid
* Gleicher Superblock, unterschiedliche Sicherheitseinstellungen für (dev 0:15, Typ nfs)

Um mehrere Mounts aus einem einzigen NFS-Export durchzuführen, wobei jeder Mount einen anderen Kontext hat, verwenden Sie die [[-o nosharecache,context]]-Optionen
* Das folgende Beispiel mountet mehrere Mounts aus einem einzigen NFS-Export, wobei jeder Mount einen anderen Kontext hat (wodurch ein einzelner Dienst auf jeden einzelnen zugreifen kann)
sudo mount server:/export/web /local/web -o nosharecache,context=„system_u:object_r:httpd_sys_content_t:s0“
sudo mount server:/export/database /local/database -o \ nosharecache,context=„system_u:object_r:mysqld_db_t:s0“

In diesem Beispiel wird [[server:/export/web]] lokal im Verzeichnis [[/local/web/]] eingebunden, wobei alle Dateien mit dem Typ [[httpd_sys_content_t]] gekennzeichnet sind, was dem Apache-HTTP-Server Zugriff gewährt. [[server:/export/database]] wird lokal in [[/local/database/]] eingebunden, wobei alle Dateien mit dem Typ [ [mysqld_db_t]] gekennzeichnet, was MariaDB den Zugriff ermöglicht
* Diese Typänderungen werden nicht auf die Festplatte geschrieben

; Wichtig

Die Option [[nosharecache]] ermöglicht es Ihnen, dasselbe Unterverzeichnis eines Exports mehrfach mit unterschiedlichen Kontexten einzuhängen, beispielsweise [[/export/web/]] mehrfach
* Hängen Sie dasselbe Unterverzeichnis eines Exports nicht mehrfach mit unterschiedlichen Kontexten ein, da dies zu einer überlappenden Einbindung führt, bei der Dateien unter zwei verschiedenen Kontexten zugänglich sind

==== Kontext-Einbindungen dauerhaft machen ====
Um Kontext-Mounts über erneutes Mounten und Neustarts hinweg persistent zu machen, fügen Sie Einträge für die Dateisysteme in die Datei [[/etc/fstab]] oder eine Automounter-Zuordnung ein und verwenden Sie den erforderlichen Kontext als Mount-Option

Das folgende Beispiel fügt einen Eintrag in [[/etc/fstab]] für eine NFS-Kontext-Einbindung hinzu
server:/export /local/mount/ nfs context="system_u:object_r:httpd_sys_content_t:s0" 0 0

[[Kategorie:Linux/SELinux/04]]