Thomas.will: Die Seite wurde neu angelegt: „== SELinux – Grundlagen und Praxis == Kein Vollkurs, sondern das Rüstzeug, mit dem ein Admin im Alltag klarkommt: was SELinux macht, wie es entscheidet, un…“

2026-07-05T07:43:38Z

Die Seite wurde neu angelegt: „== SELinux – Grundlagen und Praxis == Kein Vollkurs, sondern das Rüstzeug, mit dem ein Admin im Alltag klarkommt: was SELinux macht, wie es entscheidet, un…“

Neue Seite

== SELinux – Grundlagen und Praxis ==

Kein Vollkurs, sondern das Rüstzeug, mit dem ein Admin im Alltag klarkommt: was SELinux macht, wie es entscheidet, und welche Befehle man wirklich braucht.

== Grundkonzept: DAC vs. MAC ==

;Klassische Unix-Rechte (DAC – Discretionary Access Control)
*Der '''Besitzer''' einer Datei entscheidet über Zugriffsrechte (rwx, Owner/Group/Other)
*Läuft ein Prozess als root, kann er '''alles''' – DAC schützt nicht gegen kompromittierte Root-Prozesse

;SELinux (MAC – Mandatory Access Control)
*Zugriffsregeln werden '''zentral vom System''' vorgegeben, nicht vom Dateibesitzer
*Selbst root-Prozesse sind an die Policy gebunden
*Prinzip: '''Alles ist verboten, außer explizit erlaubt''' (Whitelist-Ansatz)

'''Merksatz:''' DAC fragt "Wem gehört die Datei?", MAC fragt "Darf dieser Prozesstyp auf diesen Ressourcentyp zugreifen?" – unabhängig vom Besitzer.

== Die drei Modi ==

{| class="wikitable"
! Modus !! Verhalten
|-
| enforcing || Regeln werden durchgesetzt, Verstöße blockiert und geloggt
|-
| permissive || Verstöße werden nur geloggt, aber '''nicht''' blockiert – Standard für Troubleshooting
|-
| disabled || SELinux komplett aus (Reboot nötig zum Aktivieren)
|}

<syntaxhighlight lang="bash">
# aktuellen Modus anzeigen
getenforce

# temporär umschalten (bis zum Reboot)
setenforce 0 # permissive
setenforce 1 # enforcing

# dauerhaft in /etc/selinux/config
SELINUX=enforcing
</syntaxhighlight>

== Security Context – das Herzstück ==

Jede Datei, jeder Prozess, jeder Port hat einen Kontext im Format:

<pre>
user:role:type:level
</pre>

Für die tägliche Praxis relevant ist fast ausschließlich das '''type'''-Feld – dieses Prinzip heißt '''Type Enforcement (TE)''' und ist der Mechanismus, der 95% der Alltagsprobleme verursacht bzw. löst.

<mermaid>
graph LR
A[Prozess mit Domain-Type z.B. httpd_t] -->|darf zugreifen auf| B[Datei mit Type z.B. httpd_sys_content_t]
A -.->|blockiert, wenn Type nicht erlaubt| C[Datei mit Type z.B. user_home_t]
</mermaid>

;Kontexte anzeigen
*<code>ls -Z /var/www/html</code> – Dateikontexte
*<code>ps -Z</code> bzw. <code>ps auxZ</code> – Prozesskontexte
*<code>id -Z</code> – eigener Kontext

== Wie eine Zugriffsentscheidung getroffen wird ==

<mermaid>
flowchart TD
Start[Prozess versucht Zugriff] --> DAC{DAC-Check klassische Unix-Rechte}
DAC -->|verweigert| Deny1[Zugriff verweigert]
DAC -->|erlaubt| MAC{SELinux Policy-Check Type Enforcement}
MAC -->|Regel erlaubt Zugriff| Allow[Zugriff gewährt]
MAC -->|keine Regel vorhanden| Mode{Modus?}
Mode -->|enforcing| Deny2[Zugriff verweigert + AVC-Log]
Mode -->|permissive| Allow2[Zugriff gewährt + AVC-Log]
</mermaid>

'''Wichtig:''' SELinux greift '''immer erst nach''' den klassischen DAC-Checks. Beide Ebenen müssen zustimmen.

== Die häufigste Fehlerquelle: falscher Kontext nach Datei-Operationen ==

Wird eine Datei kopiert, verschoben oder neu angelegt, bekommt sie oft den '''falschen''' Kontext (z. B. Datei aus dem Home-Verzeichnis nach <code>/var/www/html</code> kopiert, behält aber <code>user_home_t</code>).

<syntaxhighlight lang="bash">
# Kontext auf den in der Policy definierten Standard zurücksetzen
restorecon -Rv /var/www/html

# Kontext temporär manuell setzen (geht bei restorecon verloren!)
chcon -t httpd_sys_content_t /var/www/html/index.html

# Kontext DAUERHAFT in der Policy-Datenbank hinterlegen (übersteht restorecon)
semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
restorecon -Rv /var/www/html
</syntaxhighlight>

'''Merksatz:''' <code>chcon</code> = Pflaster, geht beim nächsten <code>restorecon</code> verloren. <code>semanage fcontext</code> = dauerhafte Regel, danach <code>restorecon</code> anwenden, damit sie greift.

== Booleans – Verhalten umschalten ohne eigene Policy ==

Booleans sind vorgefertigte Schalter für häufige Szenarien (z. B. darf Apache auf Netzwerk-Freigaben zugreifen?).

<syntaxhighlight lang="bash">
# alle Booleans mit Beschreibung auflisten
getsebool -a
semanage boolean -l

# einen Boolean dauerhaft setzen
setsebool -P httpd_can_network_connect on
</syntaxhighlight>

'''Wichtig:''' Ohne <code>-P</code> gilt die Änderung nur bis zum Reboot.

== Troubleshooting-Workflow ==

<mermaid>
flowchart LR
A[Zugriff schlägt fehl] --> B[AVC-Denial im Log suchen]
B --> C[ausearch -m avc -ts recent]
C --> D[audit2allow -w -a Klartext-Erklärung]
D --> E{Regel sinnvoll?}
E -->|ja, Standardfall| F[Boolean oder semanage fcontext nutzen]
E -->|nein, Spezialfall| G[Eigenes Modul bauen]
</mermaid>

;Logs durchsuchen
*<code>ausearch -m avc -ts recent</code> – aktuelle AVC-Denials
*<code>ausearch -m avc -ts today</code> – alle Denials von heute
*<code>sealert -a /var/log/audit/audit.log</code> – lesbare Erklärung inkl. Lösungsvorschlag (falls <code>setroubleshoot</code> installiert)

== Eigene Module bauen ==

Wenn kein passender Boolean existiert und <code>semanage fcontext</code> nicht ausreicht (z. B. eigene Anwendung mit ungewöhnlichem Zugriffsmuster):

<syntaxhighlight lang="bash">
# 1. Denials sammeln (im permissive-Modus testen, damit nichts blockiert wird)
setenforce 0
# Anwendung normal nutzen, alle Denials provozieren

# 2. Aus den Denials ein Modul generieren lassen
ausearch -m avc -ts recent | audit2allow -M meinmodul

# 3. Erzeugtes .te-File VOR dem Laden prüfen und ggf. per Hand kürzen
cat meinmodul.te

# 4. Modul kompilieren und laden
semodule -i meinmodul.pp

# 5. zurück auf enforcing und testen
setenforce 1
</syntaxhighlight>

;Bestehende Module verwalten
*<code>semodule -l</code> – geladene Module auflisten
*<code>semodule -r meinmodul</code> – Modul entfernen
*<code>semodule -i meinmodul.pp</code> – Modul (neu) laden

'''Praxis-Hinweis:''' <code>audit2allow</code> generiert oft '''zu großzügige''' Regeln (nimmt jede geloggte Aktion als "erlauben"). Das <code>.te</code>-File vor dem Laden immer durchsehen und unnötige <code>allow</code>-Zeilen streichen – sonst hebelt man den Sinn von SELinux graduell aus.

== Kontext bei Nicht-Standard-Ports ==

Läuft ein Dienst auf einem Port, der nicht in der Policy hinterlegt ist (z. B. Apache auf Port 8080 statt 80/443):

<syntaxhighlight lang="bash">
# aktuelle Port-Zuordnungen anzeigen
semanage port -l | grep http

# neuen Port zu einem bestehenden Type hinzufügen
semanage port -a -t http_port_t -p tcp 8080
</syntaxhighlight>

== Kurzreferenz der wichtigsten Befehle ==

{| class="wikitable"
! Befehl !! Zweck
|-
| <code>getenforce</code> / <code>setenforce</code> || aktuellen Modus anzeigen / temporär ändern
|-
| <code>ls -Z</code> / <code>ps -Z</code> || Datei-/Prozesskontext anzeigen
|-
| <code>restorecon -Rv</code> || Kontext auf Policy-Standard zurücksetzen
|-
| <code>chcon -t</code> || Kontext temporär setzen (übersteht restorecon nicht)
|-
| <code>semanage fcontext -a</code> || Kontext-Regel dauerhaft in Policy-DB eintragen
|-
| <code>getsebool -a</code> / <code>setsebool -P</code> || Booleans anzeigen / dauerhaft setzen
|-
| <code>ausearch -m avc</code> || AVC-Denials im Audit-Log suchen
|-
| <code>audit2allow</code> || aus Denials eine Regel/Modul generieren
|-
| <code>semodule -i/-l/-r</code> || eigenes Modul laden/auflisten/entfernen
|-
| <code>semanage port -a</code> || Port einem Type zuordnen
|}

[[Kategorie:Sicherheit]]
[[Kategorie:Rocky Linux Kurs]]

SELinux Praxis - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „== SELinux – Grundlagen und Praxis == Kein Vollkurs, sondern das Rüstzeug, mit dem ein Admin im Alltag klarkommt: was SELinux macht, wie es entscheidet, un…“