# AppArmor Strategic: Container-Isolation und User-Sessions

TL;DR / Management Summary Während AppArmor oft für Systemdienste (Artikel 145) genutzt wird, liegt seine wahre Stärke heute in der Container-Orchestrierung und der User-Isolation. Docker, Podman und LXC nutzen AppArmor-Profile als primäre Sicherheitsmauer gegen Container-Escapes. Zudem lernen wir, wie wir mit pam_apparmor jedem Benutzer beim Login ein individuelles Sicherheits-Profil zuweisen, um den Zugriff auf das restliche System radikal einzuschränken.

# 1. Einführung & Architektur

Isolation auf Prozess-Ebene.

AppArmor ist für Container ideal, da es profilbasiert arbeitet. Ein Container-Laufzeit-System weist dem Prozess beim Start ein spezifisches Profil zu.

# Die Container-Isolation (Mermaid)

graph TD
    A[Docker / Podman Engine] -->|Start Container| B[App Process]
    B --> C{AppArmor Profile: docker-default}
    C -->|Allow| D[Access to mapped Volume]
    C -->|Deny| E[Access to /etc/shadow on Host]
    C -->|Deny| F[Access to Hardware: /dev/mem]
    C -->|Deny| G[Access to other Containers]

# 2. AppArmor in Docker & LXC

Die unsichtbare Mauer.

# Docker Default Profile

Standardmäßig nutzt Docker das Profil docker-default. Es verbietet kritische Aktionen wie das Mounten von Dateisystemen oder den Zugriff auf Kernel-Module.

# Prüfung beim Start
docker run --rm -it --security-opt label=disable alpine sh
# (Deaktiviert das Profil - nur für Debugging empfohlen!)

# Custom Profiles für Microservices

Schreiben Sie spezialisierte Profile für Ihre Container, die z.B. nur den Zugriff auf Port 80 und das Daten-Volume erlauben.

# 3. pam_apparmor: User-Sessions einsperren

Sicherheit beim Einloggen.

Mit dem PAM-Modul können Sie erzwingen, dass ein User (z.B. ein externer Dienstleister) sofort nach dem Login in ein restriktives AppArmor-Profil verschoben wird.

# Einrichtung

1. Modul laden: In /etc/pam.d/sshd oder common-session: session optional pam_apparmor.so
2. Profil zuordnen: In /etc/apparmor.d/pam/ Profile für User-Rollen definieren.

# 4. Day-2 Operations: Auditing Container Escapes

Angriffe erkennen.

Verstöße von Containern tauchen im Host-Log auf. Da der Typ meist docker-default ist, lassen sie sich leicht filtern.

# Suche nach Container-Blockaden im Host-Log
sudo grep "apparmor=\"DENIED\"" /var/log/audit/audit.log | grep "docker-default"

# 5. Troubleshooting & “War Stories”

Wenn der Container ‘stumm’ bleibt.

# Story 1: “Der hängende Monitoring-Agent”

Symptom: Ein Monitoring-Agent im Docker-Container (z.B. Datadog oder Netdata) kann keine Metriken vom Host lesen. Ursache: Das docker-default Profil verbietet den Zugriff auf /proc und /sys Pfade des Hosts. Lösung: Erstellen Sie ein Custom-Profil oder nutzen Sie das Flag --security-opt apparmor=unconfined (Vorsicht: riskant!). Besser: Spezifische Pfade im Profil erlauben.

# Story 2: “Das Inode-Problem bei LXC”

Symptom: Ein LXC-Container unter Debian/Arch kann keine neuen Dateien erstellen, obwohl Platz frei ist. Ursache: Das Standard-LXC-Profil von AppArmor blockiert bestimmte Dateisystem-Operationen, die zur Verwaltung von Kontingenten nötig sind. Lösung: Nutzen Sie lxc.apparmor.profile = generated in der Container-Konfig, um ein maßgeschneidertes Profil für diesen Container erstellen zu lassen.

# 6. Fazit & Empfehlung

• Pflicht: Nutzen Sie AppArmor-Isolation für jeden produktiven Docker-Host.
• Wahl: Nutzen Sie pam_apparmor, wenn Sie Shared-Systeme (Terminalserver) betreiben, auf denen sich viele User gleichzeitig tummeln.
• Wartung: Testen Sie neue Container-Images immer erst mit dem Standard-Profil. Wenn es Fehler gibt, bauen Sie ein spezifisches Profil, anstatt die Sicherheit komplett abzuschalten.

# Anhang: Cheatsheet