# Container Security: Die Festung SELinux in RHEL

TL;DR / Management Summary Ein Container ist unter Linux nur ein isolierter Prozess. Ohne zusätzliche Sicherheit könnte ein Angreifer nach einem “Escape” den gesamten Host übernehmen. In RHEL ist SELinux der entscheidende Wächter: Es nutzt den Typ container_t, um Prozesse einzusperren, und MCS (Multi-Category Security), um sicherzustellen, dass selbst zwei identische Container nicht aufeinander zugreifen können. Wer SELinux für Container versteht, betreibt eine der sichersten Plattformen der Welt.

# 1. Einführung & Architektur

Warum Namespaces nicht reichen.

Linux-Namespaces isolieren die Sicht (was sieht der Container?), aber SELinux isoliert den Zugriff (was darf der Container tun?).

# Die Isolations-Schichten (Mermaid)

graph TD
    subgraph "Container Layer"
        A[App Process]
    end
    subgraph "Host Layer"
        B{SELinux Check}
        C[Host File System]
        D[Host Devices]
        E[Other Container]
    end
    A -->|Syscall| B
    B -->|DENY| C
    B -->|DENY| D
    B -->|DENY| E
    B -->|ALLOW| F[Container Volume]

• Typ container_t: Alle Container-Prozesse erhalten diesen Typ. Er verbietet Zugriffe auf SSH-Keys, Passwörter und Hardware-Devices des Hosts.
• MCS Labels: Jeder Container bekommt eine zufällige Kategorie (z.B. c1,c2). Nur Dateien mit exakt diesem Label sind für diesen Container lesbar.

# 2. Den Schutz in Aktion sehen

Labels prüfen.

# Prozess-Labels

podman run -d --name test-nginx nginx
ps -eZ | grep nginx
# Output: system_u:system_r:container_t:s0:c12,c45 ...

Beachten Sie den Teil :c12,c45 – das ist das MCS Label, das diesen Nginx von jedem anderen Nginx auf dem System trennt.

# 3. Dateisystem & Volume Mounting

Die häufigste Hürde.

Wenn Sie ein Host-Verzeichnis in einen Container mounten, muss SELinux dem Zugriff zustimmen.

# Der automatische Weg (:Z und :z)

Podman kann Labels für Sie setzen:

• :Z: Markiert den Inhalt als privat für diesen einen Container (nutzt die spezifische MCS Kategorie).
• :z: Markiert den Inhalt als shared (erlaubt allen Containern den Zugriff).

podman run -v /data:/mnt:Z nginx

# 4. Day-2 Operations: Custom Policies

Wenn der Container mehr darf als er soll.

Standard-Container dürfen keine Kernel-Module laden oder auf rohe Sockets zugreifen. Wenn Sie dies für Monitoring-Tools (z.B. Netdata) brauchen:

# Privilegierte Container (Vorsicht!)

podman run --privileged ...

# 5. Troubleshooting & “War Stories”

Wenn SELinux blockiert.

# Story 1: “Der Permission Denied Mount”

Symptom: Der Container startet, kann aber nicht in das gemountete Volume schreiben, obwohl chmod 777 gesetzt ist. Ursache: Das Verzeichnis auf dem Host hat noch das Label unconfined_content_t (oder ähnliches). SELinux blockiert den Zugriff für container_t. Lösung: Nutzen Sie restorecon oder das :Z Flag beim Mounten.

# Story 2: “Escape-Versuch blockiert”

Symptom: In den Audit-Logs tauchen massiv AVC Denials für den Typ container_t auf, der versucht /proc/kcore zu lesen. Ursache: Ein kompromittierter Container versucht, den Kernel-Speicher auszulesen, um Passwörter zu finden. Lösung: SELinux hat hier genau getan, was es soll. Blockieren, loggen und den Admin alarmieren. Ein “Escape” wurde erfolgreich verhindert.

# 6. Fazit & Empfehlung

• Lassen Sie SELinux an: Es ist der wichtigste Schutz für Container-Plattformen.
• Nutzen Sie Rootless: In Kombination mit SELinux bietet Rootless Podman eine unschlagbare Sicherheit.
• Monitoring: Überwachen Sie ausearch -m AVC, um Einbruchsversuche in Containern frühzeitig zu erkennen.

# Anhang: Cheatsheet