# SELinux Policies: Das Regelwerk des Kernels

TL;DR / Management Summary SELinux ist kein starres Gebilde, sondern wird durch eine Policy gesteuert – ein massives Set an Regeln, das festlegt, wer was darf. In 99% aller Enterprise-Szenarien nutzen wir die Targeted Policy: Nur potenziell gefährdete Dienste (Netzwerk-Dämons) werden eingeschränkt, der Rest läuft frei (unconfined). Für Geheimdienste oder extrem sensible Daten gibt es MLS (Multi-Level Security), bei dem Daten in Geheimhaltungsstufen (z.B. Secret, Top Secret) eingeteilt werden.

# 1. Einführung & Konzepte

Das Regelbuch lesen.

Eine Policy definiert Millionen von Interaktionen. Da dies zu komplex für Menschen wäre, bündelt Red Hat diese in Profile.

# Die Policy-Arten

1. Targeted: Standard. Schützt Dämons (HTTP, DNS, DB), aber schränkt normale User-Prozesse kaum ein.
2. Minimum: Nur die wichtigsten Dämons werden geschützt. Ideal für Embedded oder Container-Hosts.
3. Strict: ALLES wird eingeschränkt. Jeder Prozess benötigt eine explizite Erlaubnis. (Extrem schwer zu warten!).
4. MLS (Multi-Level Security): Nutzt zusätzlich das Bell-LaPadula Modell (No Read Up, No Write Down).

# 2. Targeted Policy: Der Enterprise-Standard

Sicherheit ohne Schmerzen.

In der targeted Policy laufen viele Prozesse (wie Ihre Bash-Shell) als unconfined_t. Das bedeutet, sie werden nur durch die klassischen Linux-Rechte (chmod) eingeschränkt.

# Der Schutzschild

Dienste wie httpd, named oder sshd laufen in einer “Sandbox”. Selbst wenn ein Bug in Apache es erlaubt, die Shell zu übernehmen, bleibt der Angreifer im Typ httpd_t gefangen.

graph LR
    subgraph "Targeted Policy"
        A[User Shell: unconfined_t] -->|Freedom| B[System Files]
        C[Apache: httpd_t] -->|Restricted| D[Web Files]
        C -.-x|DENY| B
    end

# 3. MLS: Multi-Level Security

Für Hochsicherheitssysteme.

MLS fügt dem Label eine Stufe hinzu: user:role:type:level.

• Stufen (Levels): s0, s1, s2…
• Kategorien: c0, c1…

Beispiel: Ein Admin auf Level s1 kann keine Dateien auf Level s2 lesen, selbst wenn er Root ist. Dies verhindert, dass Informationen zwischen verschiedenen Sicherheitsfreigaben “lecken”.

# 4. Day-2 Operations: Policy-Management

Änderungen vornehmen.

Policies sind kompiliert. Wir ändern sie meist über Booleans oder das Hinzufügen von Modulen.

# Policy-Modus prüfen

Datei: /etc/selinux/config

SELINUXTYPE=targeted

# Module auflisten

# Zeige alle geladenen Policy-Module
sudo semodule -l

# 5. Troubleshooting & “War Stories”

Wenn die Policy zu eng ist.

# Story 1: “Der eigene Service”

Symptom: Ein selbstgeschriebenes Go-Binary läuft einwandfrei, wenn es manuell gestartet wird, aber scheitert beim Start via Systemd. Ursache: Systemd startet den Prozess in einem restriktiven Kontext. Da es für Ihr Binary kein Profil in der targeted Policy gibt, wird es blockiert. Lösung: Erstellen Sie ein einfaches Modul mit audit2allow (siehe Artikel 072) oder weisen Sie dem Binary ein existierendes, passendes Label zu (z.B. bin_t).

# Story 2: “MLS Albtraum in der Cloud”

Symptom: Ein Admin aktiviert MLS auf einer AWS-Instanz und nach dem Reboot ist der SSH-Zugriff weg. Ursache: SSH-Keys und Configs haben kein MLS-Level. Der SSH-Dämon darf sie nicht mehr lesen. Lösung: Nur über serielle Konsole rettbar. MLS benötigt eine vollständige Neu-Labelung (touch /.autorelabel) und exakte Planung jedes Pfades. Warnung: Aktivieren Sie MLS niemals “einfach mal so”.

# 6. Fazit & Empfehlung

• Standard: Bleiben Sie bei Targeted. Es bietet den besten Kompromiss aus Sicherheit und Administrierbarkeit.
• MLS: Nur nutzen, wenn es eine explizite Anforderung (Military / High-Fintech) gibt und das Team speziell geschult ist.
• Isolation: Nutzen Sie lieber separate VMs oder Container (mit SELinux-Trennung), statt ein System auf MLS umzustellen.

# Anhang: Cheatsheet