# AppArmor Lab: In 5 Schritten zum eigenen Profil

TL;DR / Management Summary Ein Senior Admin schreibt für jede kritische Eigenentwicklung ein eigenes Sicherheits-Profil. In diesem Lab bauen wir ein Profil für ein hypothetisches Backup-Skript. Wir lernen den Workflow kennen: Initialisieren -> Lernen -> Analysieren -> Anwenden. Das Ziel ist ein Dienst, der nur genau das tun kann, was er soll, und keinen Millimeter mehr.

# 1. Einführung: Das Szenario

Die Ziel-Applikation.

Wir haben ein Skript /usr/local/bin/backup-tool, das:

1. Daten aus /data/prod liest.
2. Ein komprimiertes Archiv in /var/backups schreibt.
3. Logs nach /var/log/backup.log schreibt.
4. Eine E-Mail via /usr/sbin/sendmail versendet.

# 2. Schritt 1: Initialisierung (aa-genprof)

Das Gerüst bauen.

Starten Sie das Tool. Es erstellt ein Basis-Profil im Complain-Modus und fordert Sie auf, die Applikation in einem anderen Terminal zu starten.

sudo aa-genprof /usr/local/bin/backup-tool

# Was passiert im Hintergrund?

AppArmor erstellt /etc/apparmor.d/usr.local.bin.backup-tool mit Standard-Inklusions für Core-Libraries.

# 3. Schritt 2: Der Lern-Modus

Reales Verhalten aufzeichnen.

Führen Sie Ihr Skript nun mit allen Optionen aus, die im Alltag vorkommen könnten.

# In einem zweiten Terminal
sudo /usr/local/bin/backup-tool --full --notify

# 4. Schritt 3: Analyse der Ereignisse (aa-logprof)

Entscheidungen treffen.

Wechseln Sie zurück zum aa-genprof Terminal und drücken Sie (S) für Scan. AppArmor liest nun die Audit-Logs und stellt Fragen:

• Frage: /usr/local/bin/backup-tool will /data/prod/ lesen.
  • Antwort: (A)llow
• Frage: /usr/local/bin/backup-tool will /usr/sbin/sendmail ausführen.
  • Antwort: (I)nherit (Der Prozess behält das aktuelle Profil) oder (P)x (Sendmail bekommt sein eigenes Profil). Wählen Sie Px.

# 5. Schritt 4: Das Profil manuell veredeln

Den Feinschliff vornehmen.

Öffnen Sie die generierte Datei /etc/apparmor.d/usr.local.bin.backup-tool und prüfen Sie auf Wildcards.

# Bearbeiten für mehr Flexibilität
/data/prod/** r,
/var/backups/backup-*.tar.gz w,
/var/log/backup.log w,

# 6. Schritt 5: Aktivieren und Verify

Vom Test zur Produktion.

# Den Enforce-Modus aktivieren

sudo aa-enforce /usr/local/bin/backup-tool

# Die Probe aufs Exempel

Testen Sie, ob das Skript noch funktioniert, aber versuchen Sie auch einen “Einbruch”:

# Versuch, auf /etc/shadow zuzugreifen (sollte scheitern)
/usr/local/bin/backup-tool --read-file /etc/shadow
# Output: Permission Denied (auch als Root!)

# Troubleshooting: “War Stories”

Wenn der Wizard zu viel erlaubt.

# Story: “Der Wildcard-Exzess”

Symptom: Ein Admin hat bei aa-logprof immer nur auf (A)llow gedrückt. Das Ergebnis war eine Regel /** rw. Ursache: Das Skript hat temporär im Root-Verzeichnis gesucht. Der Admin hat die Warnung ignoriert. Lösung: Prüfen Sie Profile immer manuell nach der Generierung. Ein Profil mit /** ist wirkungslos und gefährlich. Nutzen Sie aa-cleanprof, um ungenutzte Regeln zu entfernen.

# Fazit & Empfehlung

• Keine Angst: AppArmor-Fehler führen nicht zum Systemabsturz, sondern nur zum Abbruch des Dienstes.
• Workflow: Nutzen Sie immer aa-genprof für den Start und aa-logprof für spätere Änderungen.
• Wahl: Für Standard-Dienste (Apache, MySQL) liefert SUSE bereits perfekte Profile mit. Fassen Sie diese nur an, wenn Sie Pfade ändern.

# Anhang: Cheatsheet