# AppArmor Profiles Masterclass: Den Prozess einsperren

TL;DR / Management Summary Ein AppArmor-Profil ist eine Textdatei, die genau festlegt, welche Ressourcen ein Programm nutzen darf. Im Gegensatz zu komplexen Binär-Policys ist die Syntax für Menschen lesbar. Ein Senior Admin nutzt Abstractions, um Standard-Aufgaben (wie DNS-Auflösung) zu erlauben, und schränkt Kernel-Capabilities (z.B. das Ändern von Dateiberechtigungen) gezielt ein. Ziel ist ein “Least Privilege” Modell für jeden kritischen Dienst.

# 1. Einführung & Architektur

Woher kommt die Erlaubnis?

Profile liegen unter /etc/apparmor.d/. Sie sind nach dem Pfad des Programms benannt (z.B. usr.sbin.httpd).

# Die Profil-Anatomie (Mermaid)

graph TD
    A[Profile: /usr/sbin/myapp] --> B[Abstractions: Shared Rules]
    A --> C[File Rules: /var/log/myapp/* rw]
    A --> D[Network Rules: tcp port 80]
    A --> E[Capabilities: chown, setuid]
    B --> B1[base]
    B --> B2[nameservice]
    B --> B3[python]

# 2. Die Syntax verstehen

Pfad-Matching und Berechtigungen.

# Pfade und Wildcards

• /path/to/file: Exakte Datei.
• /path/to/*: Alle Dateien im Verzeichnis (keine Unterordner).
• /path/to/**: Rekursiv alle Dateien und Unterordner.

# Berechtigungs-Kürzel

• r: Read (Lesen)
• w: Write (Schreiben)
• ux: Execute (Ausführen, Umgebung wird nicht vererbt)
• Px: Execute (Ausführen unter einem eigenen AppArmor-Profil)

# 3. Abstractions: Der SUSE Standard

Regeln nicht neu erfinden.

Nutzen Sie #include <abstractions/...>, um Standard-Rechtepakete zu laden.

• <abstractions/base>: Grundlegende Libraries.
• <abstractions/nameservice>: Erlaubt DNS-Auflösung via /etc/resolv.conf.
• <abstractions/openssl>: Zugriff auf CA-Zertifikate.

# Beispiel: Ein minimales Profil für ein Python-Skript

#include 

/usr/local/bin/myscript.py {
  #include 
  #include 

  /usr/bin/python3.10 ix,
  /data/input/ r,
  /var/log/myscript.log w,
  
  # Verhindere Netzwerkzugriff komplett
  deny network,
}

# 4. Day-2 Operations: Capabilities einschränken

Das wahre Härten.

Selbst wenn ein Prozess als Root läuft, kann AppArmor ihm die “Superkräfte” nehmen.

# Erlaube dem Prozess NICHT, Dateibesitzer zu ändern
deny capability chown,
# Erlaube dem Prozess NICHT, das System herunterzufahren
deny capability sys_reboot,

# 5. Troubleshooting & “War Stories”

Bugs in der Logik finden.

# Story 1: “Der hängende PDF-Export”

Symptom: Ein Webserver kann plötzlich keine Rechnungen (PDFs) mehr generieren. Die Logs zeigen einen Fehler beim Aufruf von /usr/bin/gs (Ghostscript). Ursache: Das AppArmor-Profil des Webservers erlaubt zwar den Start von Ghostscript, aber Ghostscript braucht Schreibzugriff auf /tmp, der im Profil fehlte. Lösung: Nutzen Sie aa-logprof. Es scannt die Audit-Logs und fragt interaktiv: “Soll /usr/bin/gs Zugriff auf /tmp bekommen?”. Mit (A)llow wird die Regel automatisch zum Profil hinzugefügt.

# Story 2: “Include-Reihenfolge”

Symptom: Eine deny Regel wird scheinbar ignoriert. Ursache: AppArmor verarbeitet Regeln nicht zwingend von oben nach unten. deny Regeln haben immer Vorrang vor allow Regeln innerhalb des gleichen Profils, aber includes können dies unübersichtlich machen. Lösung: Platzieren Sie Ihre deny Regeln am Ende des Profils, um die Lesbarkeit für Kollegen zu erhöhen.

# 6. Fazit & Empfehlung

• Modularität: Nutzen Sie Abstractions so oft wie möglich. Es macht Ihre Profile wartbar.
• Präzision: Seien Sie so spezifisch wie möglich. /etc/** r ist bequem, aber gefährlich. Nutzen Sie lieber /etc/myapp/* r.
• Wartung: Führen Sie nach jedem Major-App-Update aa-logprof aus, um zu sehen, ob neue Pfade benötigt werden.

# Anhang: Cheatsheet