Erstellen eines benutzerdefinierten AppArmor-Profils unter SUSE Linux

SUSE kündigte SLES 16.0 am 4. November 2025 an. SELinux ersetzt AppArmor als standardmäßiges, obligatorisches Zugriffskontroll-Framework. Wenn auf Ihrem Server SLES 16 läuft, gehen Sie nicht davon aus, dass AppArmor installiert oder aktiv ist: Prüfen Sie vor der Verwendung dieser Befehle, welches Framework von Ihrer Bereitstellung unterstützt wird. Die folgende Vorgehensweise orientiert sich an der AppArmor-Dokumentation von SUSE SLES 15 SP7, wo AppArmor standardmäßig installiert und aktiv ist.

Unter SLES 15 SP7 empfiehlt es sich für eine benutzerdefinierte Anwendung aa-genprof, ein Startprofil erstellen zu lassen, die Anwendung im Beschwerdemodus zu testen, jede protokollierte Anfrage zu überprüfen und anschließend die Wirksamkeit des Profils zu bestätigen. Das Beispiel verwendet eine hypothetische ausführbare Datei unter /usr/local/bin/report-worker; ersetzen Sie diese durch den tatsächlichen Pfad Ihrer Anwendung.

Bevor Sie beginnen

AppArmor-Profile sind Textrichtlinien, die unter gespeichert werden /etc/apparmor.d. Das apparmor-utilsPaket stellt die Profiling-Tools bereit. Überprüfen Sie den Host und identifizieren Sie die eigentliche ausführbare Datei, einschließlich der Frage, ob eine systemd-Unit einen Wrapper- oder Kindprozess startet:

sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker

SUSE gibt an, dass AppArmor bei SLES 15-Installationen standardmäßig aktiviert ist. Falls die Tools oder das vollständige AppArmor-Muster fehlen, installieren Sie das Muster mit dem Befehl `apparmor install apparmor` sudo zypper in -t pattern apparmor. Wenn AppArmor nicht aktiv ist, beheben Sie die Ursache, bevor Sie ein Profil erstellen, anstatt sich darauf zu verlassen, dass eine Profildatei allein Schutz bietet. Ein Profil ist an einen Ausführungspfad gebunden; das Profilieren eines Wrappers, während die eigentliche Arbeitslast als andere Binärdatei ausgeführt wird, kann dazu führen, dass der wichtige Prozess nicht geschützt ist.

Profil erstellen und verfeinern

1. Starten Sie den Generator. Beenden Sie die Anwendung, falls sie bereits läuft, und starten Sie anschließend die Profilgenerierung:

   sudo systemctl stop report-worker
   sudo aa-genprof /usr/local/bin/report-worker

   

   Der Dienstname ist ein Beispiel. Verwenden Sie den tatsächlichen Gerätenamen oder lassen Sie den Stoppbefehl weg, falls das Programm nicht ausgeführt wird. aa-genprofFalls kein Profil vorhanden ist, wird ein ungefähres Profil erstellt, das Programm in den Lernmodus versetzt, neu geladen und im Protokoll entsprechend markiert. Im Lernmodus werden zwar Anfragen außerhalb der Richtlinien protokolliert, aber zugelassen; es handelt sich um einen temporären Lernzustand, nicht um eine Durchsetzungsmaßnahme.

2. Testen Sie das Verhalten der Anwendung unter realen Bedingungen. Lassen Sie den Generator geöffnet. Starten Sie in einem anderen Terminal den Dienst und führen Sie repräsentative Jobs oder Funktionen aus:

   sudo systemctl start report-worker
   sudo journalctl -f

   

   Berücksichtigen Sie den normalen Startvorgang, erwartete Ein- und Ausgabepfade, geplante Aufgaben, Fehlerbehandlung und alle Hilfsprogramme, die die Anwendung startet. Ein Profil kann nur Anfragen erfassen, die während des Tests generiert werden. Verwenden Sie keine produktionskritischen Workloads, nur um Ereignisse zu generieren; eine sichere Testumgebung und repräsentative Testdaten sind vorzuziehen.

3. Prüfen Sie jede Zugriffsanfrage. Drücken Sie erneut die aa-genprofentsprechende Taste, Sum den markierten Protokollbereich zu durchsuchen. Entscheiden Sie für jede Anfrage, ob die Anwendung die Datei, die Funktion oder den Übergang eines untergeordneten Programms tatsächlich benötigt. Erlauben Sie den engsten sinnvollen Pfad und die erforderlichen Berechtigungen. Akzeptieren Sie eine Abstraktion, wenn sie eine häufige Aufgabe präzise abdeckt; verwenden Sie einen Glob-Pfad nur, wenn die übereinstimmenden Dateien dieselben Vertrauens- und Zugriffsanforderungen erfüllen. Lehnen Sie Anfragen ab oder überspringen Sie diese, wenn sie zufällig oder unerklärt sind.

   

   Achten Sie besonders auf die Ausführung von Anfragen. Ein unkontrollierter Übergang kann dazu führen, dass ein Kindelement die Richtlinie des Elternelements umgeht; verwenden Sie ihn daher nur, wenn dies aus triftigen Gründen erforderlich ist. Wiederholen Sie die Übung und den Scan-Zyklus nach dem Hinzufügen gültiger Regeln. Sobald das Profil das getestete Verhalten abdeckt, schließen Sie den Generator ab. SUSE weist darauf hin, dass aa-genprofdas Profil nach Abschluss eines neuen Lernzyklus normalerweise in den Erzwingungsmodus wechselt.

4. Überprüfen Sie die generierte Richtlinie. In diesem Beispielpfad wandelt die Namenskonvention von SUSE Schrägstriche im Ausführungspfad in Punkte um, was zu folgendem Ergebnis führt /etc/apparmor.d/usr.local.bin.report-worker: Überprüfen Sie das Ergebnis, anstatt generierte Regeln als automatisch sicher zu betrachten:

   sudo less /etc/apparmor.d/usr.local.bin.report-worker

   

   Prüfen Sie, ob das Profil die beabsichtigte ausführbare Datei benennt, die erforderlichen Includes verwendet und nur Zugriff auf die Konfigurations-, Daten-, Protokoll-, Socket- und Hilfsprogramme gewährt, die die Anwendung tatsächlich benötigt. Vermeiden Sie weit gefasste Regeln wie uneingeschränkten Zugriff auf /ein gesamtes beschreibbares Verzeichnis, nur um eine Zugriffsverweigerung zu unterdrücken. Die Anwendung verwendet weiterhin die üblichen Unix-Berechtigungen; AppArmor fügt eine separate Zugriffsebene hinzu.

5. Legen Sie den gewünschten Modus explizit fest. Nach der Überprüfung erzwingen Sie das Profil für das benutzerdefinierte Programm:

   sudo aa-enforce /usr/local/bin/report-worker

   

   Wenn Sie das Profil nach dem Beenden des Generators manuell bearbeitet haben, laden Sie das Profilset mit dem Befehl `suse update` neu sudo systemctl reload apparmor. SUSE dokumentiert das Neuladen als erneutes Scannen von Profilen, ohne laufende Prozesse zu beeinträchtigen. Starten Sie den Anwendungsdienst neu, damit die neue Richtlinie auf den zugehörigen Prozess angewendet wird.

Überprüfen Sie den Antrag im Rahmen der Durchsetzung.

Führen Sie dieselben repräsentativen Aufgaben erneut aus, während sich das Profil im Erzwingungsmodus befindet. Vergewissern Sie sich, dass der Dienst startet, die vorgesehenen Eingaben liest, die erwarteten Ausgaben schreibt und die erforderlichen Hilfs- oder Netzwerkoperationen ausführen kann. Überprüfen Sie anschließend sowohl den Profilstatus als auch die letzten Kernelmeldungen.

sudo aa-status
sudo journalctl -k -g apparmor --since today

Die benutzerdefinierte ausführbare Datei sollte als geladen und im Erzwingungsmodus angezeigt werden. AppArmor-Verweigerungen im Kernel-Journal kennzeichnen Anfragen, die von der Richtlinie blockiert wurden. Verwenden Sie diese, um einen tatsächlichen Anwendungsfehler zu diagnostizieren, nicht als Grund, jeden protokollierten Pfad zuzulassen. Bei einer legitimen fehlenden Berechtigung führen Sie den Befehl aus, sudo aa-logprofprüfen Sie den Vorschlag, passen Sie die Regel präzise an, laden Sie die Anwendung neu, falls Sie sie manuell bearbeitet haben, und führen Sie den betroffenen Anwendungspfad erneut aus.

Für einen kontinuierlich laufenden Dienst, dessen Profiling Neustarts oder längere Beobachtungszeiten umfassen muss, dokumentiert SUSE einen separaten systemweiten Workflow mit aa-autodepwiederholten aa-complainScans aa-logprof. Die eigenständige aa-genprofMethode ist einfacher, wenn der Lernlauf für den gesamten Test geöffnet bleiben kann. Beide Workflows können das Anwendungsverhalten nicht ableiten, das nie getestet wurde. Überprüfen Sie daher das Profil regelmäßig, wenn sich Software oder Konfiguration ändert.

Quellen

• SUSE: Was ist neu in SUSE Linux Enterprise Server 16.0?
• SUSE SLES 15 SP7: Erste Schritte mit AppArmor
• SUSE SLES 15 SP7: Profile über die Befehlszeile erstellen
• SUSE SLES 15 SP7: Profilkomponenten und Syntax