# AppArmor Deep Dive: Applikations-Sicherheit durch Isolation

TL;DR / Management Summary AppArmor ist ein Mandatory Access Control (MAC) System, das standardmäßig in Ubuntu und Debian aktiv ist. Im Gegensatz zu Standard-Berechtigungen (DAC), die auf User-Ebene arbeiten, schränkt AppArmor das Verhalten von Prozessen direkt ein. Selbst wenn eine Applikation (z.B. Nginx) eine Sicherheitslücke hat und als Root übernommen wird, verhindert AppArmor, dass der Hacker Dateien liest oder Befehle ausführt, die nicht explizit im Profil erlaubt sind.

# 1. Einführung & Architektur

DAC vs. MAC.

• DAC (Discretionary Access Control): “Darf User X die Datei Y lesen?” (chmod/chown).
• MAC (Mandatory Access Control): “Darf der Prozess /usr/sbin/nginx die Datei /etc/shadow lesen?” (Profile).

AppArmor nutzt Pfad-basierte Profile, um den Kernel-Zugriff zu steuern.

graph TD
    A[Application Execution] --> B{Kernel Check}
    B -->|Standard DAC| C[Check User/Group Permissions]
    C -->|Pass| D{MAC: AppArmor Check}
    D -->|Match Profile| E[Allow or Deny based on Rules]
    D -->|No Profile| F[Allow - Unconfined]
    E --> G[File / Network / Capability Access]

# 2. Status & Profil-Modi

Das System überwachen.

AppArmor Profile können in verschiedenen Zuständen sein:

1. Enforce: Regeln werden hart durchgesetzt. Verstöße werden blockiert und geloggt.
2. Complain: Verstöße werden nur geloggt, aber nicht blockiert (ideal für Tests).
3. Disabled: Das Profil ist inaktiv.

# Status prüfen

sudo aa-status

Dies zeigt Ihnen genau, welche Prozesse aktuell “gefangen” (confined) sind und welche Profile geladen wurden.

# 3. Verwaltung von Profilen

Bändigen von Diensten.

Profile liegen unter /etc/apparmor.d/.

# Profil-Modus ändern

# In den Test-Modus versetzen
sudo aa-complain /usr/sbin/nginx

# In den harten Modus versetzen
sudo aa-enforce /usr/sbin/nginx

# Profile neu laden

sudo systemctl reload apparmor

# 4. Day-2 Operations: Eigene Profile & Debugging

Wenn die Applikation ‘Permission Denied’ sagt.

Wenn eine Applikation nicht funktioniert, obwohl die Berechtigungen stimmen, ist oft AppArmor schuld.

# Den Fehler finden

Verstöße werden in das System-Log geschrieben.

# Suche nach 'audit' oder 'apparmor' Meldungen
journalctl -xe | grep -i apparmor
# oder modern
sudo aa-notify -s 1 -v

# Das Profil anpassen

Profile nutzen eine einfache Syntax:

• r: Read
• w: Write
• px: Execute

Beispiel /etc/apparmor.d/usr.sbin.nginx:

/var/www/html/ r,
/var/www/html/** r,
/var/log/nginx/* w,

# 5. Troubleshooting & “War Stories”

Praxis-Fallen.

# Story 1: “MySQL startet nach Pfad-Änderung nicht”

Symptom: Das Datenverzeichnis von MySQL wurde auf /mnt/data/mysql verschoben. Berechtigungen sind korrekt (chown mysql:mysql), aber MySQL startet mit “Permission Denied”. Ursache: Das AppArmor Profil für MySQL erlaubt nur Zugriffe auf /var/lib/mysql. Lösung: Bearbeiten Sie /etc/apparmor.d/tunables/alias oder fügen Sie den Pfad zum MySQL-Profil hinzu.

# Story 2: “Das verschwundene Log”

Symptom: Eine Applikation wird gehackt, aber im Log steht nichts vom Einbruch. Ursache: AppArmor hat den Angriff zwar blockiert (Silent Deny), aber das Logging war nicht aktiv. Lösung: Stellen Sie sicher, dass auditd läuft, damit AppArmor-Verstöße zentral und persistent geloggt werden.

# 6. Fazit & Empfehlung

• Lassen Sie es an: Schalten Sie AppArmor niemals global aus (apparmor=0 im Bootloader). Es ist Ihre letzte Verteidigungslinie.
• Complain First: Wenn Sie eigene Applikationen paketieren, lassen Sie sie erst im Complain-Modus laufen, sammeln Sie die Logs und bauen Sie daraus das Profil.
• Docker/LXC: Diese nutzen eigene AppArmor-Profile, um Container voneinander und vom Host zu isolieren.

# Anhang: Cheatsheet