82 SELinux/AppArmor Profile

Mandatory Access Control (MAC) zählt zu den robustesten Sicherheitsmechanismen des Linux-Ökosystems. Während Namespaces, Capabilities und Seccomp isolieren, kontrolliert MAC den tatsächlichen Zugriff auf Dateien, Prozesse und Systemobjekte. SELinux und AppArmor sind dabei die zwei dominierenden Implementierungen, mit grundverschiedenen Philosophien, aber ähnlichem Ziel: präzise, regelbasierte Beschränkung dessen, was Containerprozesse tun dürfen – auch dann, wenn sie bereits in Namespaces laufen oder Capabilities besitzen. Podman und Kubernetes integrieren MAC-Profile auf unterschiedlichen Abstraktionsebenen und machen sie zu unverzichtbaren Bausteinen eines sicheren Containerbetriebs.

82.1 Grundprinzip: Zugriffskontrolle durch Labels und Profile

MAC-Systeme funktionieren nicht wie klassische UNIX-Permissions oder ACLs. Sie deklarieren nicht „was darf ein User?“, sondern „was darf ein Prozesskontext?“. Das heißt: Ein Containerprozess wird nicht über UID/GID oder Capabilities beurteilt, sondern über sein Sicherheitslabel (SELinux) oder sein Profil (AppArmor).

Der Schutzmechanismus wirkt unabhängig von Benutzerrechten oder Namespaces. Selbst ein Container-Root (UID 0 im User Namespace) ist vollständig kontrolliert.

Modellhaft:

Egal wie viele Privilegien der Prozess besitzt – das Label entscheidet.

82.2 SELinux: Label-basierte Sicherheit

SELinux arbeitet mit Kontexten, die aus vier Teilen bestehen:

user:role:type:level

Container arbeiten praktisch immer mit type-basierten Regeln. Podman setzt automatisch geeignete Labels, wenn SELinux aktiv ist (z. B. in Fedora, RHEL, CentOS Stream).

Standardlabel für Containerprozesse:

system_u:system_r:container_t:s0

Standardlabel für Containerdateisysteme:

system_u:object_r:container_file_t:s0

82.2.1 Der entscheidende Teil: type

Der Type definiert, welche Interaktionen erlaubt sind. container_t darf beispielsweise:

• nur in container_file_t-Bereiche schreiben
• nicht auf hostweite Filesystemobjekte zugreifen
• nicht fremde Containerdateien lesen
• keine Kernelbereiche verändern

Damit wird verhindert, dass ein Container, selbst mit eskalierten Capabilities, unautorisiert auf Hostressourcen zugreift.

82.2.2 Bind-Mounts und SELinux-Zonen

Podman erkennt SELinux automatisch und zwingt korrekte Labels:

-v /data/app:/app:Z

Varianten:

• :Z → exklusives Label für diesen Container
• :z → Shared-Label für mehrere Container

Fehlt dieses Labeling, verweigert SELinux jeden Zugriff. Der Container sieht das Verzeichnis – aber der Kernel blockiert alle Operationen.

82.2.3 SELinux in Kubernetes

Kubernetes übergibt Labels über den securityContext:

securityContext:
  seLinuxOptions:
    type: container_t

In OpenShift wird dies noch umfangreicher genutzt:

• jede Pod-Sandbox erhält eigene SELinux-Level
• Projekte werden über Multi-Category Security isoliert
• Pod-Hopping wird damit nahezu unmöglich

82.3 AppArmor: profilbasierte Kontrolle

AppArmor arbeitet anders als SELinux. Statt Labels für jedes Objekt existieren feste Profile für Programme und Container. Eine AppArmor-Regel definiert:

• welche Dateien ein Containerpfad lesen darf
• welche Netzwerksockets geöffnet werden dürfen
• ob ptrace erlaubt ist
• ob spezielle Systemcalls erlaubt sind

Ein vereinfachtes Beispielprofil:

profile my-container-default {
  network inet,
  deny /etc/shadow r,
  deny /proc/sys/** w,
  /app/** r,
  /data/** rw,
}

AppArmor denkt nicht in Typen, sondern in „Policies pro Prozess“.

82.3.1 AppArmor und Podman

Podman kann AppArmor-Profile explizit übergeben:

podman run --security-opt apparmor=my-container-default ...

Fehlt ein Profil, nutzt Podman in AppArmor-Distributionen das Profil:

docker-default

Ein konservatives, aber brauchbares Sicherheitsprofil.

82.3.2 AppArmor in Kubernetes

Kubernetes aktiviert AppArmor per Annotation:

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/app: localhost/my-profile

AppArmor ist im Kubernetes-Umfeld vor allem in Ubuntu-basierten Clustern relevant.

82.4 Philosophische Unterschiede

Beide Modelle haben Stärken – SELinux ist mächtiger, AppArmor zugänglicher.

82.5 Zusammenspiel mit anderen Sicherheitsmechanismen

MAC-Systeme sind der letzte Verteidigungswall, wenn alle anderen Mechanismen versagen. Die Isolationsarchitektur lässt sich so ausdrücken:

Auf jeder Ebene kann ein Prozess eingeschränkt werden:

• Namespaces begrenzen Sichtbarkeit
• Capabilities begrenzen privilegierte Aktionen
• Seccomp begrenzt Systemcalls
• SELinux/AppArmor begrenzen Datei- und Objektzugriffe

MAC ist die instanzielle „Hard Enforcement Layer“.

82.6 Typische Fehler in Containerumgebungen

82.6.1 1. Mounts ohne SELinux-Labels

Beispiel:

-v /var/lib/data:/data

Ohne :Z oder :z darf der Container nicht schreiben – und Administratoren deaktivieren aus Frust SELinux. Stattdessen: korrekt labeln.

82.6.2 2. „Setz alles auf permissive“

Wird oft getan, wenn Logs unverständlich erscheinen. Konsequenz: Der gesamte Sicherheitsgewinn verpufft.

82.6.3 3. Ungepflegte AppArmor-Profile

Profile müssen regelmäßig an neue Pfade, Versionen und Binärdateien angepasst werden.

82.6.4 4. CAP_SYS_ADMIN + lax MAC → fatal

Wer Capabilities aufweicht, aber MAC deaktiviert, zerstört das gesamte Sicherheitsmodell.

82.7 Empfehlungen für Architekten

• SELinux aktiviert lassen, niemals deaktivieren
• AppArmor-Profile explizit erstellen, statt nur docker-default zu nutzen
• Bind-Mounts immer korrekt labeln
• Pod-Sicherheit nicht an Images hängen – MAC wirkt unabhängig
• Rootless + MAC = starke Defense-in-Depth
• Für Multi-Tenant: SELinux bevorzugen (OpenShift-like Architektur)

SELinux und AppArmor sind keine optionalen Add-ons, sondern die höchste Ebene der Container-Sicherheitsschichten. Sie greifen, wenn alles andere bereits versagt hat. Wer Containerarchitekturen ernsthaft schützt, muss MAC-Profile verstehen, einsetzen und regelmäßig überprüfen – unabhängig davon, ob Podman, Docker oder Kubernetes im Spiel sind.