Linux/SELinux/Praxis/3

SCHRITT 3.1: Der Prozess als SELinux-Subjekt

Bis zu diesem Punkt wurden Dateien und Verzeichnisse betrachtet. In der Terminologie von SELinux sind all diese Elemente Objekte (Objects). Sie sind passiv. Eine Datei kann sich nicht selbst lesen oder löschen.

Im klassischen Linux hängen die Rechte eines Prozesses davon ab, unter welcher Benutzerkennung er läuft (UID/GID). In SELinux erhält ein Prozess beim Start seinen eigenen Sicherheitskontext. Dieser Kontext bestimmt vollständig, was der Prozess im System tun darf – unabhängig davon, ob es sich um einen Root-Prozess oder um einen gewöhnlichen Benutzerprozess handelt.

• Um den Kontext laufender Prozesse anzuzeigen, wird bei ps die Option -Z verwendet:

ps -eZ | grep sshd

Ausgabe:

# ps -Z
LABEL                               PID TTY          TIME CMD
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 90819 pts/1 00:00:00 sudo
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 90820 pts/1 00:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 91782 pts/1 00:00:00 ps

Prinzipien der SELinux-Arbeitsweise bei Prozessen

Die Grundlage von SELinux ist der Mechanismus der zwingenden Zugriffskontrolle auf Basis von Typen – Type Enforcement (TE). In diesem Modell wird jedem Element im System ein bestimmter Bezeichner zugewiesen, der als Typ (type) bezeichnet wird.

• Bei passiven Entitäten (Dateien, Verzeichnisse, Sockets) wird diese Kennzeichnung einfach als Typ bezeichnet (file context / type). Bei einer Datei beschreibt das Feld type den Objekttyp.
• Bei aktiven Entitäten (Prozessen) wird dieselbe Kennzeichnung historisch und konzeptionell als Domäne (domain) bezeichnet. Beim Prozess beschreibt das Feld type die Domäne des Subjekts.

Wenn ein Prozess versucht, eine Aktion auszuführen, bewertet SELinux die Anfrage anhand der Gesamtheit der Attribute von Subjekt und Objekt. Die klassischen UNIX-/DAC-Prüfungen erfolgen dabei zuerst: Wenn DAC die Operation bereits verweigert (zum Beispiel weil dem Benutzer die herkömmlichen Leserechte fehlen), kommt SELinux gar nicht mehr zum Zug, und es kann auch keinen AVC-Eintrag geben.

Wenn keine DAC-Hindernisse vorliegen, vergleicht SELinux den Prozesskontext und den Objektkontext mit der geladenen Policy. Die Grundlogik lautet default deny: Zugriff wird nur dann erlaubt, wenn eine Regel existiert, die die benötigte Interaktion explizit zulässt.

Algorithmus der Zugriffsprüfung nach DAC im Type Enforcement:

1. Identifikation des Subjekts: Es wird die Domäne des anfragenden Prozesses bestimmt (zum Beispiel ein Webserver in der Domäne httpd_t).
2. Identifikation des Objekts: Es wird der Typ der Zielressource bestimmt (zum Beispiel eine Datei mit dem Typ httpd_sys_content_t).
3. Bestimmung von Klasse und Aktion: Es werden die Objektklasse (file) und die angeforderte Aktion (read) festgelegt.
4. Prüfung der Policy (Regelsuche): Der Kernel greift auf den Access Vector Cache (AVC) oder auf die geladene Policy zu, um nach einer erlaubenden Regel zu suchen.

SCHRITT 3.2: Policy und Zugriffsregeln. Das Werkzeug sesearch

Wie bereits besprochen, wird im TE-Modell ein Prozess als Subjekt betrachtet, das in einer bestimmten Domäne arbeitet, während ein Objekt als Entität mit einem bestimmten Typ gilt. Für SELinux ist dies die zentrale Grundlage der Entscheidungsfindung: Die Policy legt fest, welche Domänen auf welche Typen zugreifen dürfen, auf Objekte welcher Klassen und mit welchen Aktionen (permissions).

Eine TE-Regel hat die folgende Form:

allow source_type target_type:object_class { permission };

• source_type
  • Dies ist der Typ des Subjekts. Bei einem Prozess ist das seine Domäne. Wenn ein Prozess in httpd_t, sshd_t oder passwd_t läuft, steht genau dieser Wert auf der linken Seite der TE-Prüfung.
• target_type
  • Dies ist der Typ des Objekts, mit dem das Subjekt interagiert: zum Beispiel httpd_sys_content_t, tmp_t, shadow_t, user_home_t. Derselbe Prozess kann mit unterschiedlichen Objekten arbeiten, und die Prüfung wird für jedes Paar aus Domäne und Typ separat durchgeführt.
• object_class
  • SELinux gruppiert Objekte in Klassen.
  • Bei einer Datei und einem Verzeichnis können sich die Berechtigungen beispielsweise unterscheiden. Daneben existieren auch Klassen wie filesystem, tcp_socket, netif, node und weitere. Jede Klasse besitzt ihre eigene Menge möglicher Permissions.
• permission
  • Dies ist die konkrete Aktion, die erlaubt werden muss: read, write, open, search, getattr, create, append, rename usw.

---

Zugriff gewähren

Der Ablauf zur Gewährung eines Zugriffs auf ein Objekt sieht grundsätzlich wie folgt aus:

• einen bereits vorhandenen geeigneten Typ für das Objekt auswählen
• ein Boolean aktivieren*, das die benötigten konditionalen Regeln einschaltet
• oder die Policy erweitern bzw. ändern, falls die Standard-Policy eine solche Interaktion nicht vorsieht (weil die erforderlichen Typen oder Booleans nicht existieren)

* Boolean ist ein logischer Schalter für bereits in der Policy vorhandene Regelsätze. Ausführlicher wird dieses Konzept in den folgenden Lektionen zu SELinux Booleans behandelt.

---

Arbeit mit Regeln mithilfe von sesearch

sesearch ist ein Werkzeug aus dem SETools-Paket zur Suche nach Regeln in der SELinux-Policy.

Verwendung

sesearch -A -s <SOURCE_TYPE> -t <TARGET_TYPE> -c <CLASS> -p <PERM>

Parameter	Bedeutung
-A	allow- und allowxperm-Regeln suchen
-s / --source	source type oder source attribute*
-t / --target	target type oder target attribute*
-c / --class	Objektklasse
-p / --perm	permission oder Liste von permissions

* Type Attributes. Nicht mit Dateiattributen verwechseln.

• Das folgende Beispiel kann direkt im Terminal ausgeführt werden:

sesearch -A -s unconfined_t -t tmp_t -c file

Ausgabe:

# sesearch -A -s unconfined_t -t tmp_t -c file
allow files_unconfined_type file_type:file execmod; [ allow_execmod ]:True
allow files_unconfined_type file_type:file { append create execute execute_no_trans getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr unlink watch watch_mount watch_reads watch_sb watch_with_perm write };

Hier ist das Ergebnis einer Suche nach erlaubenden Regeln (allow) für ein Subjekt in der Domäne unconfined_t beim Zugriff auf Objekte des Typs tmp_t zu sehen, eingeschränkt auf die Objektklasse file.

• Type Attributes. Statt konkreter Typen erscheinen hier files_unconfined_type und file_type. Dies sind Type Attributes – also Gruppen, in denen jeweils viele Typen zusammengefasst sind.
• Die erste Zeile enthält eine separate Regel für execmod, die mit Speicherschutz zusammenhängt; darauf wird an dieser Stelle noch nicht näher eingegangen. Der Teil "[ allow_execmod ]:True" bedeutet, dass diese Regel nur aktiv ist, wenn das Boolean allow_execmod eingeschaltet ist.
• Die zweite Zeile enthält eine erlaubende Regel für alle Typen, die zum Type Attribute files_unconfined_type gehören, und umfasst einen großen Satz von Operationen auf Dateien (also Objekten mit dem Attribut file_type und der Klasse file).
  • Die Aktionen stehen in geschweiften Klammern: { append create execute ... write }
• Daraus folgt, dass ein Prozess in der Domäne unconfined_t seine Rechte über das Attribut files_unconfined_type erhält. Das bedeutet, dass jeder Prozess, der unter einem „unconfined“-Benutzerkontext läuft, praktisch umfassende Kontrolle über temporäre Dateien besitzt, da tmp_t zum globalen Attribut file_type gehört.

Wichtig ist, dass der Doppelpunkt hier nicht „Teil eines Typnamens“ bedeutet. Er trennt target und object_class.

Optionen

Wichtige sesearch-Optionen zusätzlich zu den oben gezeigten:

--allow, --dontaudit, --auditallow

• Auswahl des Typs der zu suchenden Regeln, ähnlich wie -A
• --allow – sucht nur nach allow
• --auditallow – Regeln, die vorschreiben, erlaubte Aktionen zu protokollieren
• --dontaudit – Regeln zur Unterdrückung der Protokollierung von Zugriffverweigerungen

-p, --perm

sesearch -A -s httpd_t -c file -p read

• Standardmäßig sucht -p nach Regeln, die mindestens eine der angegebenen Permissions enthalten.
• Für strengere Abfragen (am Beispiel read,open):
  • -ep read,open – findet nur Regeln, bei denen die Menge der Permissions genau der angegebenen Menge entspricht
  • -Sp read,open – findet Regeln, deren Permission-Menge eine Obermenge der angegebenen Menge ist. Das ist besonders nützlich, um Regeln zu finden, die die benötigten Rechte vollständig abdecken.

-b, --bool

sesearch -A -b httpd_read_user_content

• Sucht nach conditional rules, die an ein Boolean gebunden sind.
  • Conditional rules werden im Abschnitt zu SELinux Booleans im Detail behandelt; hier genügt der Hinweis, dass es sich um bedingte Regeln im Sinne von if / else handelt.
• Eine solche Anfrage ist nützlich, wenn bekannt ist, dass ein bestimmtes Verhalten von einem SELinux-Boolean gesteuert wird und sichtbar werden soll, welche Regeln dadurch beeinflusst werden.

-ds und -dt

Sehr wichtige Optionen für eine präzise Analyse:

• -ds – verlangt, dass die Source explizit angegeben ist
• -dt – verlangt, dass das Target explizit angegeben ist

Wie in den obigen Beispielen zu sehen ist, kann man ohne -ds / -dt Regeln erhalten, die über ein Attribut ermittelt wurden. Diese Optionen unterbinden die implizite Suche über Attribute.

-rs, -rt, -rc, -rd, -rb

sesearch -A -rs '.*httpd.*' -c file

• Diese Optionen aktivieren Regexp-Matching für source, target, class, default beziehungsweise Boolean.

---

Praktische Aufgabe

Es soll geprüft werden, ob der Prozess sshd Dateien im Home-Verzeichnis eines Benutzers lesen darf.

• Zuerst werden die Kontexte (Typen) der Dateien im Home-Verzeichnis angezeigt:

# ls -Z1
unconfined_u:object_r:user_home_t:s0 other
    system_u:object_r:user_home_t:s0 testfile

Die Benutzerdateien haben den Typ user_home_t; dieser Wert wird festgehalten.

• Danach wird der Typ des Prozesses sshd betrachtet:

# ps -eZ | grep sshd
system_u:system_r:sshd_t:s0         592 ?        00:00:00 sshd

Der Prozess sshd hat den Typ sshd_t.

• Anschließend erfolgt die Suche nach einer Regel in der Policy-Datenbank:

sesearch -A -s sshd_t -t user_home_t -c file -p read

...Hm, nichts gefunden! Müsste sshd nicht Zugriff auf das Verzeichnis ~/.ssh haben? Dann sollte der Typ des versteckten Verzeichnisses .ssh geprüft werden.

• Prüfung:

# ls -dZ ~/.ssh
unconfined_u:object_r:ssh_home_t:s0 /root/.ssh

Der Dienst sshd benötigt für seine Arbeit keinen Zugriff auf beliebige Benutzerdateien, sondern nur auf das Verzeichnis .ssh.

• Daher wird das Vorhandensein einer passenden Regel in der Policy geprüft:

sesearch -A -s sshd_t -t ssh_home_t -c file -p read

Ausgabe:

allow ssh_server ssh_home_t:file { getattr ioctl lock open read };

Damit lässt sich sicher feststellen, dass sshd auf Dateien im Typ ssh_home_t zugreifen darf, und zwar mit folgenden Rechten:

• Lesen von Attributen (getattr) – der Prozess kann Metadaten der Datei abfragen, etwa Größe, Eigentümer, Berechtigungen oder Änderungszeit
• Steuerung von I/O-Parametern (ioctl) – wird häufig von Bibliotheken für die korrekte Arbeit mit Datenströmen verwendet
• Setzen von Sperren (lock) – sshd kann Dateisperren setzen; das ist wichtig, um gleichzeitige Schreibzugriffe mehrerer Prozesse zu verhindern
• Öffnen der Datei (open) – selbst wenn ein Leserecht vorhanden ist, kann der Kernel ohne explizites open dem Prozess keinen Dateideskriptor für die weitere Arbeit bereitstellen

SCHRITT 3.3: Domain Transition

Nach der Analyse von allow wird sichtbar, dass SELinux zwei unterschiedliche Fragen beantwortet:

1. Was darf ein bereits laufender Prozess tun?
2. Welche Domäne soll dieser Prozess beim Start eines Programms überhaupt erhalten?

Die zweite Frage beantwortet der Mechanismus des Übergangs von einer Domäne in eine andere (domain transition).

Ein Domain Transition ist ein streng kontrolliertes Ereignis, das in der Regel beim Start eines neuen Programms stattfindet.

Regeln für den Übergang

Ein Domänenwechsel ist fast immer an den Moment gebunden, in dem der aktuelle Prozess die Ausführung einer neuen Binärdatei über den Systemaufruf execve() auslöst.

In diesem kritischen Moment analysiert SELinux drei Komponenten:

1. Den Kontext des aktuellen Prozesses (Source Domain)
2. Den Kontext der ausführbaren Datei (File Context / Entrypoint)
3. Die Policy-Regeln, die den Übergang in eine neue Domäne erlauben (Target Domain)

Die Policy-Regel sieht wie folgt aus:

type_transition source_domain executable_type:process target_domain;

• Beispiel:

type_transition init_t crond_exec_t:process crond_t;

• Wenn ein Prozess in der Domäne init_t eine Datei vom Typ crond_exec_t ausführt, soll der neue Prozess in die Domäne crond_t wechseln.

---

Voraussetzungen für den Übergang in eine neue Domäne

Damit der Übergang tatsächlich stattfindet, verlangt SELinux nicht nur eine einzige Regel, sondern zusätzlich mindestens drei logische Bedingungen.

• Die Quell-Domäne muss das Recht transition in die Ziel-Domäne besitzen.
• Die ausführbare Datei muss aus der Quell-Domäne heraus ausgeführt werden dürfen.
• Diese Datei muss für die Ziel-Domäne als entrypoint zugelassen sein.

Erforderliche Regeln (drei erlaubende Regeln plus die eigentliche Transition-Regel):

allow source_domain target_domain:process transition;
allow source_domain executable_type:file { execute };
allow target_domain executable_type:file entrypoint;
type_transition source_domain executable_type:process target_domain;

Entrypoint

Damit eine Datei einen Prozess in eine neue Domäne überführen kann, muss sie einen speziellen Typ besitzen, der in der Policy als Entrypoint für die Ziel-Domäne definiert ist.

Reales Beispiel

• Die Datei /usr/bin/passwd besitzt den Typ passwd_exec_t.
• Genau dieser Typ ist in der Policy als entrypoint für die Domäne passwd_t erlaubt.
• Deshalb führt die Ausführung von passwd dazu, dass der Prozess in passwd_t wechselt.
• Für die Domäne passwd_t existiert dann bereits die Berechtigung, mit Dateien des Typs shadow_t zu arbeiten, zum Beispiel mit /etc/shadow.

Der entrypoint-Mechanismus schützt das System vor dem Fall, dass ein Angreifer versucht, ein eigenes schädliches Skript zu starten, um sich darüber Zugang zu einer geschützten Domäne zu verschaffen.

---

Domain Transition dient der Isolation von Privilegien. Ein Prozess erhält nicht im Voraus alle denkbaren Rechte. Stattdessen gelangt er nur über eine streng definierte ausführbare Datei in eine spezialisierte Domäne.

---

Einschränkung von Übergängen

Die Begrenzung unerwünschter Domain Transitions basiert auf den folgenden Prinzipien:

1. Harte Adressierung der Regeln

Betrachtet wird die folgende Regel:

type_transition unconfined_t mysvc_exec_t:process mysvc_t;

• In diesem Fall gilt die Transition nur für die Ausführung von Dateien des Typs mysvc_exec_t aus der Domäne unconfined_t.

1. Die Ziel-Domäne definiert selbst über entrypoint, über welche Dateien sie überhaupt betreten werden darf.
   • Fremde Binärdateien können ohne eine passende entrypoint-Regel keinen nicht autorisierten Zugang erhalten.
2. Der Übergang muss eindeutig sein.
   • Die SELinux-Policy erlaubt keine zwei unterschiedlichen Ziel-Domänen für dieselbe Kombination aus source domain + executable type + process.
   • Ein Policy-Kompilierungsfehler verhindert die Definition zweier verschiedener Ziel-Domänen für denselben Fall.

Anzeige von type_transition-Regeln

Zur Anzeige von Transition-Regeln wird die bereits bekannte sesearch-Option -T verwendet.

• Beispiel:

sesearch -T -t passwd_exec_t -c process

Ausgabe:

# sesearch -T -t passwd_exec_t -c process
type_transition accountsd_t passwd_exec_t:process passwd_t;
type_transition auditadm_t passwd_exec_t:process passwd_t;
type_transition guest_t passwd_exec_t:process passwd_t;
type_transition secadm_t passwd_exec_t:process passwd_t;
type_transition smbd_t passwd_exec_t:process passwd_t; [ samba_domain_controller ]:True
type_transition staff_t passwd_exec_t:process passwd_t;
type_transition sysadm_t passwd_exec_t:process passwd_t;
type_transition user_t passwd_exec_t:process passwd_t;
type_transition xguest_t passwd_exec_t:process passwd_t;

Wenn ein Prozess aus der Domäne user_t (gewöhnlicher Benutzer), staff_t oder sogar guest_t eine Datei mit dem Typ passwd_exec_t ausführt, muss der Kernel versuchen, den Kontext des neuen Prozesses auf passwd_t umzuschalten.

• Zusätzlich kann geprüft werden, ob die Transition nach passwd_t selbst erlaubt ist:

sesearch -A -t passwd_t -c process -p transition

Ausgabe:

# sesearch -A -t passwd_t -c process -p transition
allow accountsd_t passwd_t:process transition;
allow auditadm_t passwd_t:process transition;
allow guest_t passwd_t:process transition;
allow passwd_t passwd_t:process { dyntransition fork getattr getcap getpgid getrlimit getsched getsession noatsecure rlimitinh setcap setfscreate setkeycreate setpgid setrlimit setsched setsockcreate share sigchld siginh sigkill signal signull sigstop transition };
allow secadm_t passwd_t:process transition;
allow smbd_t passwd_t:process transition; [ samba_domain_controller ]:True
allow staff_t passwd_t:process transition;
allow sysadm_t passwd_t:process transition;
allow user_t passwd_t:process transition;
allow xguest_t passwd_t:process transition;

Die zweite sesearch -A-Ausgabe bestätigt, dass all diese Domänen (Source Domains) eine offizielle Berechtigung für diesen Übergang besitzen.

• Abschließend wird noch das entrypoint-Recht geprüft:

sesearch -A -s passwd_t -t passwd_exec_t -c file -p entrypoint

Ausgabe:

# sesearch -A -s passwd_t -t passwd_exec_t -c file -p entrypoint
allow passwd_t passwd_exec_t:file { entrypoint execute getattr ioctl lock map open read };

Die Logik dieser Regel ist die folgende: Der automatische Übergang in die Domäne passwd_t ist nur dann gültig, wenn er über eine ausführbare Datei des Typs passwd_exec_t ausgelöst wurde, die für diese Domäne als entrypoint definiert ist.

Zusätzlich sind die Standardrechte für die Programmausführung sichtbar (execute, read, open). Dadurch kann die Domäne passwd_t ihren eigenen Programmcode korrekt lesen und ausführen, nachdem die Kontrolle an sie übergeben wurde.

---

Wann kein Übergang stattfindet

Nicht jeder Programmstart führt zu einem Domänenwechsel. Wenn für das Paar Quell-Domäne + Typ der ausführbaren Datei in der Policy keine passende type_transition-Regel existiert, bleibt der Prozess in der Regel in seiner bisherigen Domäne.

Das ist jedoch nur dann möglich, wenn die Policy die Ausführung der Datei ohne Domänenwechsel erlaubt, also über die Permission execute_no_trans.

Mit anderen Worten gibt es bei execve() zwei mögliche Varianten:

1. Übergang in eine neue Domäne
   • wenn eine type_transition-Regel existiert
   • und alle notwendigen Bedingungen erfüllt sind (transition, entrypoint, Berechtigung zur Ausführung der Datei)
2. Ausführung ohne Übergang
   • wenn kein Übergang definiert ist
   • die aktuelle Domäne aber execute_no_trans für diesen Dateityp besitzt

Wenn die Policy hingegen weder eine Transition noch eine Ausführung ohne Übergang erlaubt, wird der Programmstart verweigert.

SCHRITT 3.4: Type Attributes und seinfo

In SELinux arbeitet die Policy nur selten direkt mit einzelnen Typen. Stattdessen wird die Abstraktion der Type Attributes verwendet – also logische Gruppen von Typen, die nach funktionalen Kriterien zusammengefasst sind.

Zur Anzeige von Informationen über Attribute und die darin enthaltenen Typen dient das Werkzeug seinfo.

• Es wird geprüft, welche Typen das Attribut httpdcontent enthält:

seinfo -a httpdcontent -x

Ausgabe:

# seinfo -a httpdcontent -x

Type Attributes: 1
   attribute httpdcontent;
        httpd_apcupsd_cgi_content_t
        httpd_apcupsd_cgi_ra_content_t
        httpd_apcupsd_cgi_rw_content_t
        httpd_awstats_content_t
        httpd_awstats_ra_content_t
        ...
        httpd_user_ra_content_t
        httpd_user_rw_content_t
        httpd_webalizer_content_t
        httpd_webalizer_ra_content_t
        httpd_webalizer_rw_content_t

Dank der Type Attributes kann eine einzige Regel formuliert werden, anstatt für jeden einzelnen Typ eine separate Regel definieren zu müssen.

Damit wirken Type Attributes wie ein Mechanismus der „Vererbung“ von Regeln.

Effective Permissions

Aus dem bisher Gesagten wird deutlich, dass die Rechte einer Domäne nicht nur von direkten allow-Regeln abhängen, sondern auch von Regeln, die Typen indirekt über Attribute erhalten.

• Bei der Analyse solcher geerbten Regeln hilft das bereits bekannte Werkzeug sesearch. In der Standardverwendung löst es Attribute auf. Das lässt sich mit dem folgenden Befehl nachvollziehen:

sesearch -A -s httpd_t -t httpd_sys_content_t -c file -p read

• Nun derselbe Aufruf mit Parametern, die eine Auflösung über Attribute unterbinden:

sesearch -A -s httpd_t -t httpd_sys_content_t -c file -p read -ds -dt

seinfo

seinfo ist ein Werkzeug zur Inventarisierung und strukturellen Analyse einer SELinux-Policy. Während sesearch die Frage beantwortet, „gibt es eine solche Regel?“, beantwortet seinfo die Frage: „aus welchen Entitäten besteht die geladene Policy?“

Die Syntax sieht wie folgt aus:

seinfo [OPTIONS] [EXPRESSION] [POLICY]

Zentrale Einsatzgebiete von seinfo:

• Prüfung, ob ein Typ, Attribut, eine Rolle, ein Benutzer oder ein Boolean existiert
• Suche nach den Attributen, zu denen ein bestimmter Typ bzw. eine bestimmte Domäne gehört
• Ermittlung, welche Typen in einem bestimmten Attribut enthalten sind
• Anzeige, welche Rollen und Benutzer in der Policy überhaupt definiert sind
• Überblick über die Struktur der Policy insgesamt

---

Optionen

Aufruf ohne Optionen

seinfo

• Liefert eine Zusammenfassung. Angezeigt werden die Anzahl von Typen, Attributen, Rollen, Benutzern, Booleans und weiteren Policy-Objekten.

-x, --expand

seinfo -t sshd_t -x
seinfo -a file_type -x

• Die wichtigste Option
• Aktiviert eine erweiterte Ausgabe
• Bei Typen bedeutet dies in der Regel, dass die Mitgliedschaft in Attributen sichtbar wird.
• Bei Attributen wird die Liste der enthaltenen Mitglieder ausgegeben.

-t [TYPE], --type [TYPE]

seinfo -t httpd_t -x

• Fordert Informationen zu einem Typ an, also insbesondere, in welchen Attributen dieser Typ enthalten ist.

-a [ATTR], --attribute [ATTR]

seinfo -a daemon -x

• Fordert Informationen zu einem Attribut an, also welche Typen diesem Attribut zugeordnet sind.

-r [ROLE], --role [ROLE]

• Abfrage einer Rolle

-u [USER], --user [USER]

• Abfrage eines Benutzers

-b [BOOL], --bool [BOOL]

• Abfrage eines Booleans

POLICY als Argument

Es kann nicht nur die aktuell aktive Policy analysiert werden, sondern auch eine konkrete Policy-Datei.

seinfo -t httpd_t -x /etc/selinux/targeted/policy/policy.*

Schritt 3.5: SELinux Booleans

In den vorherigen Etappen wurde deutlich, dass die Rechte von Domänen fest in der Policy definiert sind. Doch was ist zu tun, wenn das Standardverhalten eines Dienstes leicht angepasst werden soll? Zum Beispiel dann, wenn dem Apache-Webserver erlaubt werden soll, sich mit einer entfernten Datenbank zu verbinden oder E-Mails zu versenden.

Dafür ein eigenes Policy-Modul von Grund auf zu schreiben, ist oft zu aufwendig und für Standardfälle unnötig. Für genau solche typischen Szenarien stellen die SELinux-Entwickler Booleans bereit.

Booleans sind in die Policy integrierte Schalter (on/off), mit denen bestimmte Regelblöcke (Conditional Rules) innerhalb der bereits kompilierten Policy aktiviert oder deaktiviert werden.

Ein und derselbe Prozess in httpd_t, smbd_t oder einer anderen Service-Domäne kann nach dem Umschalten eines Boolean zusätzlichen Zugriff auf Objekttypen erhalten, die in der Policy bereits vorgesehen sind.

---

Regeln, die mit booleans arbeiten, besitzen einen Zusatzblock in eckigen Klammern:

allow httpd_t user_home_t:file { getattr ioctl lock open read }; [ httpd_read_user_content ]:True

• [ httpd_read_user_content ]:True bedeutet, dass sich diese Regel im if-Zweig befindet. Sie ist nur dann aktiv, wenn der Schalter httpd_read_user_content auf ON steht.
• [ httpd_read_user_content ]:False bedeutet, dass sich diese Regel im else-Zweig befindet. Sie ist nur dann aktiv, wenn der Schalter httpd_read_user_content auf OFF steht.

---

Werkzeuge

getsebool

Wird verwendet, um den aktuellen Zustand eines Boolean anzuzeigen.

• Alle aktuellen Booleans anzeigen:

getsebool -a

• Einen einzelnen Boolean anzeigen:

getsebool httpd_use_nfs

setsebool

Wird verwendet, um den Zustand eines Boolean zu ändern.

• Boolean einschalten (temporär):

setsebool ftpd_anon_write on

• Boolean einschalten (persistent):

setsebool -P ftpd_anon_write on

• Wenn mehrere Booleans gesetzt werden, müssen sie in der Form parameter=wert angegeben werden:

setsebool ftpd_anon_write=on ftpd_use_passive_mode=on

semanage boolean

Wird verwendet, um Boolean-Einstellungen als Teil der Policy-Konfiguration zu verwalten. Außerdem lassen sich damit eine menschenlesbare Beschreibung jedes Schalters sowie dessen Standardwert anzeigen.

• Alle Booleans mit Beschreibung und Werten anzeigen (aktuell und Standard):

semanage boolean -l

• Beschreibung eines bestimmten Boolean suchen:

semanage boolean -l | grep httpd

• Zustand eines Boolean ändern (funktional ähnlich zu setsebool -P):

semanage boolean -m --on ftpd_anon_write

Praktisches Beispiel

Aufgabe

Es soll erreicht werden, dass die Web-Anfrage mit curl eine Datei lesen kann, die als auf NFS liegend gelabelt ist – und zwar ausschließlich mithilfe des Boolean-Mechanismus.

Lösung

• Vorbereitung der Umgebung:

mkdir -p /var/www/html/nfs_test
echo "Hello from NFS" > /var/www/html/nfs_test/index.html
chcon -R -t nfs_t /var/www/html/nfs_test
setenforce 1 # Enforcing-Modus aktivieren

• Versuch, die Seite aus dem NFS-Verzeichnis mit curl abzurufen:

curl -I http://localhost/nfs_test/index.html

Ergebnis:

# curl -I http://localhost/nfs_test/index.html
HTTP/1.1 403 Forbidden
...

• Relevante Rechte und zugehörige Booleans prüfen:

semanage boolean -l | grep httpd
semanage boolean -l | grep nfs
sesearch -A -s httpd_t -t nfs_t -c file -p read

Mithilfe von sesearch lässt sich der Lösungsweg bestimmen:

# sesearch -A -s httpd_t -t nfs_t -c file -p read
allow httpd_t nfs_t:file { execute execute_no_trans getattr ioctl map open read }; [ ( httpd_builtin_scripting && use_nfs_home_dirs && httpd_enable_homedirs ) ]:True
allow httpd_t nfs_t:file { execute execute_no_trans getattr ioctl map open read }; [ httpd_builtin_scripting && httpd_use_nfs ]:True
allow httpd_t nfs_t:file { execute getattr ioctl map open read }; [ httpd_use_nfs && httpd_enable_cgi ]:True
allow httpd_t nfs_t:file { getattr ioctl lock open read }; [ use_nfs_home_dirs && httpd_enable_homedirs ]:True

Es ist zu erkennen, dass in der Liste unter anderem httpd_use_nfs vorkommt, dieses Boolean allein jedoch nicht ausreicht, damit eine passende Regel aktiv wird. Deshalb wird entschieden, httpd_builtin_scripting als zweiten Aktivierungsfaktor zu verwenden.

• Den aktuellen Zustand von httpd_use_nfs und httpd_builtin_scripting prüfen:

getsebool httpd_use_nfs httpd_builtin_scripting

• Beide Booleans testweise temporär aktivieren:

setsebool httpd_use_nfs=on httpd_builtin_scripting=on

• Erneute Prüfung:

curl -I http://localhost/nfs_test/index.html

Ergebnis:

HTTP/1.1 200 OK
...

Erfolgreich!

• Wenn das Verhalten den Erwartungen entspricht, können die Änderungen persistent gespeichert werden:

setsebool -P httpd_use_nfs=on httpd_builtin_scripting=on

SCHRITT 3.6: Einschränkungen oberhalb von allow

In den vorherigen Schritten konnte der Eindruck entstehen, dass das Vorhandensein einer allow-Regel automatisch zu einem erfolgreichen Zugriff führt. In SELinux können jedoch oberhalb von allow zusätzliche Mechanismen greifen.

Nach der normalen TE-Prüfung kann der Kernel weitere Einschränkungen anwenden: constrain / validatetrans, spezielle Prüfungen für ausführbaren Speicher, globale policycap-Schalter sowie die Logik von no_new_privs. Deshalb tritt in der praktischen Diagnose häufig die Situation auf: Eine allow-Regel ist vorhanden, die Operation wird aber trotzdem verweigert.

Constraints (Einschränkungen)

Ein constraint ist eine zusätzliche Bedingung, die zusätzlich zu einer bereits gefundenen allow-Regel erfüllt sein muss. Ein constraint gewährt keine neuen Rechte, sondern schränkt den Geltungsbereich einer bereits vorhandenen allow-Regel weiter ein.

constrain { object_class_list } { permissions } ( expression );

Beispiel

allow unconfined_t ext_gateway_t:process transition;
constrain process transition ( r1 == r2 );

• Die Transition-Regel besagt, dass der Übergang grundsätzlich erlaubt ist.
• Das constraint fügt eine weitere zwingende Bedingung hinzu: Der Übergang ist nur zulässig, wenn die Rolle der Quelle mit der Rolle des Ergebnisses übereinstimmt.

---

validatetrans (validate transition): Eine spezielle Form von Einschränkungen, die nur bei relabel-Operationen greift. Dabei werden gleichzeitig drei Parameter ausgewertet: der alte Dateikontext, der neue Dateikontext und der Kontext des Prozesses, der die Änderung vornimmt.

validatetrans schützt das System davor, dass ein kompromittierter Prozess mit dem Recht relabel eine normale Textdatei in eine ausführbare Binärdatei (bin_t) oder in eine Passwortdatei (shadow_t) umwandelt. Für solche Aktionen wird in der Regel das Vorhandensein eines speziellen Attributs verlangt, etwa can_change_system_roles.

validatetrans { class_id } ( expression );

---

Anzeige

Das Werkzeug seinfo kann sowohl normale constraints als auch validatetrans-Regeln anzeigen.

seinfo --constrain process
seinfo --validatetrans file

---

Memory Protection (Speicherschutz)

SELinux ist tief in das Speicherverwaltungssubsystem des Kernels integriert, um vor der Ausnutzung von Schwachstellen wie etwa Buffer Overflows zu schützen. Selbst wenn ein Prozess eine Datei ausführen darf, kann SELinux bestimmte Speicheroperationen trotzdem verbieten.

• Für die Klasse process definiert SELinux unter anderem die folgenden Permissions:
  • execmem – erlaubt es, eine anonyme oder privat eingeblendete writable memory mapping als ausführbar zu markieren
  • execstack – erlaubt es, den Haupt-Stack des Prozesses als ausführbar zu markieren
  • execheap – erlaubt es, den Heap-Speicher des Prozesses als ausführbar zu markieren
• Für die Klasse file existiert die Permission execmod, die typischerweise mit der Ausführung einer im Speicher modifizierten Dateiabbildung zusammenhängt.
• Zusätzlich gibt es die Klasse memprotect mit der Permission mmap_zero, die Versuche kontrolliert, per mmap() in den niedrigen Adressraum zu mappen.

Damit kontrolliert SELinux nicht nur den Zugriff auf Dateien oder das Recht auf einen Domain Transition, sondern auch die Sicherheit des Ausführungsmodells von Code im Speicher.

Deshalb kann ein Programm zwar berechtigt sein, eine Bibliothek zu lesen und sogar zu starten, dennoch aber einen Denial erhalten – etwa wegen des Versuchs, ein writable+executable Mapping zu erzeugen, Code vom Stack auszuführen, einen ausführbaren Heap zu verwenden oder eine modifizierte Dateimapping zu laden.

Anzeige

Zur Analyse von Problemen mit Speicherschutzmechanismen wie execmem werden in erster Linie die zugehörigen Regeln geprüft; zusätzlich kann auch ein relevantes Boolean abgefragt werden:

sesearch -A -s DOMAIN_T -c process -p execmem,execstack,execheap
sesearch -A -s DOMAIN_T -t FILE_TYPE_T -c file -p execmod
getsebool -a | grep execmem

---

Policy capabilities

Policy capabilities (policycap) sind globale Fähigkeiten der geladenen Policy, also eingebaute Schalter für bestimmte Betriebsmodi von SELinux. Sie ermöglichen es der Policy, beim Hinzukommen neuer Kernel-Funktionen abwärtskompatibel zu bleiben.

Beispiele

• network_peer_controls: Aktiviert moderne Prüfungen für Netzwerkpakete.
• open_perms: Aktiviert die Prüfung der Permission open für Dateien; früher wurden nur read und write geprüft.
• always_check_network: Erzwingt, dass SELinux Netzwerk-Labels und netzwerkbezogene SELinux-Prüfungen immer als aktiv behandelt, auch wenn die entsprechenden Netzwerkmechanismen aktuell nicht explizit konfiguriert sind.

Anzeige

seinfo --polcap -x

---

No New Privileges (NNP)

Das Flag no_new_privs (NNP) ist ein Mechanismus des Linux-Kernels, der seit Kernel-Version 3.5 existiert. Jeder Prozess kann dieses Bit setzen. Danach wird es über fork, clone und execve vererbt und kann nicht mehr zurückgesetzt werden.

Für SELinux ist das besonders wichtig, weil auch ein Domain Transition bei execve() als Privilegienänderung betrachtet werden kann. Im aktuellen SELinux-Modell sind bei aktivierter Policy Capability nnp_nosuid_transition für bestimmte Domain Transitions zusätzliche Permissions erforderlich:

• process2:nnp_transition – wenn der Thread mit no_new_privs läuft
• process2:nosuid_transition – wenn der Übergang von einem mit nosuid gemounteten Dateisystem ausgeht
  • Wenn die Capability nnp_nosuid_transition deaktiviert ist, werden solche Übergänge üblicherweise durch bounded transitions eingeschränkt; darauf wird etwas später noch eingegangen.

---

typebounds

Ein bounded transition ist ein Domain Transition, bei dem die neue Domäne als eingeschränkte Version der alten Domäne gilt und keine Privilegien über die der Ausgangsdomäne hinaus erhält. Das bedeutet: Der Kernel erlaubt einen Domain Transition bei aktivem NNP, wenn in der Policy explizit definiert ist, dass die neue Domäne in ihren Rechten nicht weiter reicht als die alte.

Dies wird über die Regel typebounds festgelegt.

typebounds SRC_T DST_T;

Wenn eine solche Regel existiert, versteht der Kernel, dass ein Prozess beim Wechsel nach DST_T keine Rechte erhält, die er in SRC_T nicht bereits hatte, und erlaubt die Operation deshalb auch mit gesetztem no_new_privs-Flag.

Prüfung, ob typebounds vorhanden ist:

seinfo --typebounds -x

---

Beispiel

Wenn in der Policy die folgende Regel vorhanden ist:

allow SRC_T DST_T:process transition;

• dann ist für einen Prozess mit NNP zusätzlich die folgende Regel erforderlich:

allow SRC_T DST_T:process2 nnp_transition;

Anzeige

• Standard-Domain-Transition prüfen:

sesearch -A -s SRC_T -t DST_T -c process -p transition

• Erlaubnis für den Übergang mit NNP prüfen:

sesearch -A -s SRC_T -t DST_T -c process2 -p nnp_transition

• Erlaubnis für den Übergang von einem nosuid-gemounteten Dateisystem prüfen:

sesearch -A -s SRC_T -t DST_T -c process2 -p nosuid_transition

---

audit2why

An dieser Stelle ist es sinnvoll, auch das Werkzeug audit2why zu erwähnen, das bei der Analyse komplexer Situationen und von AVC-Denials hilfreich sein kann.

audit2why liest Meldungen aus dem audit.log und versucht, die Ursache einer Verweigerung in menschenlesbarer Form zu erklären, anstatt nur rohe AVC-Einträge anzuzeigen.

Die praktische Verwendung beschränkt sich im Wesentlichen auf die folgenden Varianten:

• Alle AVC-Meldungen anzeigen:

audit2why -a

• Einen benutzerdefinierten Satz von AVCs über ausearch an audit2why weitergeben:

ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent -i | audit2why
ausearch -m AVC,USER_AVC,SELINUX_ERR -c httpd -i | audit2why

audit2why kann Zeit sparen oder zumindest einen Hinweis darauf geben, in welche Richtung bei der Problemlösung weiter analysiert werden sollte.

SCHRITT 3.7: Dateierzeugung durch Prozesse

Standardmäßig gilt in SELinux eine einfache Vererbungsregel: Eine neu erzeugte Datei erhält den Typ des Verzeichnisses, in dem sie erstellt wird. Wenn zum Beispiel ein Webserver (httpd_t) eine temporäre Datei in /tmp (tmp_t) anlegt, erhält diese Datei standardmäßig ebenfalls den Typ tmp_t. Das ist jedoch oft weder sicher noch praktikabel, weil auch andere Prozesse Zugriff auf tmp_t haben können. Wie lässt sich erreichen, dass der Webserver seine temporären Dateien automatisch mit dem passenden Typ versieht, etwa httpd_tmp_t?

Das manuelle Setzen eines Labels mit chcon skaliert aus drei Gründen schlecht:

• chcon löst das Problem nur für ein bereits existierendes Objekt, nicht aber für die nächste Datei, die der Dienst eine Sekunde später erzeugt
• Das gesetzte Label ist temporär und kann durch restorecon oder ein vollständiges Relabeling wieder überschrieben werden
• Die Logik des Labelings wird aus der Policy in manuelle Administratoraktionen verlagert, was fast immer zu Konfigurationsdrift und schwer diagnostizierbaren Fehlern führt

File Transitions

SELinux löst dieses Problem elegant durch automatische Kernel-seitige Labelvergabe im Moment der Dateierzeugung (policy-based labeling). Die Grundidee ist, dass die Policy nicht eine bereits existierende Datei steuert, sondern das Ergebnis der Erzeugungsoperation.

Dafür wird eine Regel vom Typ File Type Transition verwendet. Sie sagt dem Kernel: Wenn ein Prozess in Domäne X ein Objekt der Klasse Y in einem Verzeichnis des Typs Z erstellt, muss diesem Objekt automatisch der Typ W zugewiesen werden.

type_transition <domain> <parent_dir_type>:<class> <new_type>;

Beispiel

type_transition httpd_t tmp_t:file httpd_tmp_t;

Wenn der Webserver (httpd_t) in einem Verzeichnis vom Typ tmp_t eine Datei (file) erzeugt, muss dieser Datei unmittelbar bei der Erzeugung das Label httpd_tmp_t zugewiesen werden.

Wie zu sehen ist, beginnt die Regel ebenso mit type_transition wie eine Domain-Transition-Regel. Der wesentliche syntaktische Unterschied besteht jedoch darin, dass hier explizit eine Objektklasse wie file angegeben wird und nicht die Prozessklasse.

Wichtig: type_transition legt nur das Label des neuen Objekts fest. Die Regel vergibt keine Rechte wie create, add_name, write usw.

Einschränkungen

Ein gewöhnlicher File Transition ist dann sinnvoll, wenn alle Objekte einer bestimmten Klasse, die in einem bestimmten Container erzeugt werden, denselben Typ erhalten sollen.

Wenn ein Dienst in seinem Runtime-Verzeichnis beispielsweise immer Hilfsdateien mit derselben Funktion erzeugt, ist kein Dateiname erforderlich: Domäne des Prozesses, Verzeichnistyp und Objektklasse reichen aus.

Das Problem beginnt dann, wenn derselbe Prozess im selben Verzeichnis mehrere unterschiedliche Objekte erzeugt, die verschiedene SELinux-Typen erhalten sollen.

Named File Transition

Ein named file transition ist derselbe type_transition, jedoch mit einer zusätzlichen Bedingung: Der Parameter basename des neu erzeugten Objekts muss mit dem angegebenen Namen übereinstimmen.

type_transition <domain> <parent_dir_type>:<class> <new_type> "<basename>";

Ein named transition vergleicht nicht den Pfad, sondern ausschließlich den Basename.

• Der Vergleich erfolgt als exakte Übereinstimmung. Der Name muss Zeichen für Zeichen identisch sein
• Reguläre Ausdrücke und Wildcard-Symbole werden hier nicht unterstützt
• Wie beim normalen File Transition betrifft der Mechanismus nur die initiale Erzeugung eines Objekts und korrigiert keine bereits existierenden falsch gelabelten Dateien

Beispiel

type_transition unconfined_t admin_home_t:dir ssh_home_t ".ssh";

Wenn ein Prozess vom Typ unconfined_t innerhalb eines Verzeichnisses vom Typ admin_home_t ein Verzeichnis mit dem Namen .ssh anlegt, erhält das neue Verzeichnis den Typ ssh_home_t.

Wichtiger Hinweis

<u>Wenn ein Label restorecon oder setfiles überstehen soll, muss es zusätzlich auf Ebene der file_contexts abgebildet sein.</u>

Arbeit mit File Transitions

• Hinsichtlich des Geltungsbereichs ist wichtig, dass file transition-Regeln nicht nur für file und dir gelten, sondern auch für andere Objektklassen, etwa sock_file, fifo_file, chr_file oder blk_file
• Für die Suche nach Regeln und die Diagnose von Problemen mit File Transitions ist sesearch mit der Option -T besonders nützlich:

sesearch -T -s <source_domain> -t <parent_dir_type>

• Beispiel einer Prüfung:

# sesearch -T -s user_t -t tmp_t
type_transition user_t tmp_t:dir user_tmp_t;
type_transition user_t tmp_t:fifo_file user_tmp_t;
type_transition user_t tmp_t:file user_tmp_t;
type_transition user_t tmp_t:lnk_file user_tmp_t;
type_transition user_t tmp_t:sock_file user_tmp_t;

Interpretation der Ausgabe: Wenn ein Prozess in der Domäne user_t in einem Verzeichnis vom Typ tmp_t ein Objekt erzeugt – etwa eine Datei, ein Verzeichnis, einen Link oder ein Socket –, dann soll diesem Objekt der Typ user_tmp_t zugewiesen werden.

SCHRITT 3.8: restorecond, der Hintergrund-Korrektor für Labels

In dieser Lektion wird der Dienst restorecond behandelt – ein Hintergrundmechanismus zur automatischen Wiederherstellung von Labels. In modernen Linux-Distributionen wird dieser Daemon in der Regel nicht standardmäßig installiert, und viele seiner Aufgaben werden heute effizient direkt im Kernel über File-Transition-Regeln sowie durch eingebaute Mechanismen von systemd gelöst. Dennoch ist das Verständnis von restorecond notwendig: Das Werkzeug taucht weiterhin in bestimmten Spezialfällen auf, und seine Funktionsweise ist für korrektes Troubleshooting von zentraler Bedeutung.

restorecond

restorecond (Restore Context Daemon) ist ein Hintergrundprozess (Dienst), der bestimmte Dateien und Verzeichnisse in Echtzeit überwacht, und zwar mithilfe der Kernel-Subsystems inotify.

Wenn in einem überwachten Verzeichnis eine neue Datei erscheint oder ein Objekt in ein überwachten Verzeichnis verschoben wird, prüft restorecond sofort dessen Label. Wenn das aktuelle Label nicht mit dem in der SELinux-Referenzdatenbank (file_contexts) hinterlegten Label übereinstimmt, setzt der Daemon automatisch das korrekte Label zurück.

restorecond überwacht nicht das gesamte Dateisystem – das würde die Server-Performance massiv beeinträchtigen. Stattdessen beobachtet der Dienst nur die Pfade, die explizit in seinen Konfigurationsdateien eingetragen sind:

• /etc/selinux/restorecond.conf – die systemweite Konfigurationsdatei. Hier werden typischerweise für das System kritische Pfade eingetragen, in denen Benutzer oder Skripte häufig Dateien mit falschen Labels erzeugen. (Beispiele: /etc/resolv.conf, /root/*, /var/run/*)
• /etc/selinux/restorecond_user.conf – die benutzerspezifische Konfiguration. Sie wird verwendet, um Dateien in Home-Verzeichnissen zu überwachen, zum Beispiel SSH-Schlüssel (~/.ssh/*) oder Dateien unter ~/.public_html/, damit Webserver oder SSH-Daemonen nicht durch fehlerhafte Labels den Zugriff verlieren.

Für die Wiederherstellung der Labels verwendet restorecond denselben Mechanismus wie restorecon.

Manuelles Setzen von Labels und restorecond

Das manuelle Setzen eines Labels auf einem überwachten Pfad kann in mindestens drei Situationen instabil sein:

• Der Daemon restorecond wird gestartet oder liest seine Konfiguration erneut ein
• Die Datei wird unter demselben Namen neu erzeugt
• Die Datei wird atomar ersetzt – etwa per Umbenennung oder Verschieben (mv) in ein überwachtes Verzeichnis. Viele Programme aktualisieren Dateien nicht durch direktes Überschreiben, sondern nach dem Muster „temporäre Datei erzeugen und anschließend per move über die alte Datei legen“. In einem solchen Fall wird die Label-Wiederherstellung durch restorecond ausgelöst.

Dadurch kann das Verhalten auftreten, dass ein Administrator ein Label mit chcon setzt, das Label aber kurze Zeit später wieder auf den ursprünglichen Zustand zurückgesetzt wird. In einer solchen Situation sollte zuerst geprüft werden, ob der Dienst restorecond im System aktiv ist.

Funktionsweise

• Zunächst liest restorecond seine Konfiguration und bestimmt für jeden Eintrag:
  • das Verzeichnis, das überwacht werden soll
  • den Dateinamen oder das Basename-Muster, mit dem eingehende Ereignisse verglichen werden
• Danach setzt restorecond einen inotify-Watch auf das Verzeichnis

---

Wichtig ist, dass restorecond nicht an der Kernel-Logik der Label-Vergabe im Moment der Dateierzeugung beteiligt ist. Zuerst wird das Objekt erzeugt, danach trifft ein inotify-Ereignis ein, und erst anschließend ruft der Daemon für den konkreten Pfad den restorecon-Mechanismus auf. Genau das ist der grundlegende Unterschied zu file transition, das bereits im Kernel während der Erzeugung eines Objekts greift.

---

Pfadvergleich

Der Vergleich erfolgt anhand der letzten Pfadkomponente, weil Verzeichnis und Basename getrennt verarbeitet werden. Das bedeutet, dass Muster mit * nur in der letzten Komponente funktionieren:

/root/.ssh/*
~/public_html/*

Anzeige

• Status des Dienstes über systemd prüfen:

systemctl status restorecond

• Vorhandensein des Prozesses und seine SELinux-Domäne prüfen:

ps -eZ | grep restorecond_t

• restorecond-Konfiguration anzeigen:

cat /etc/selinux/restorecond.conf