AppArmor.

AppArmor ist ein Linux Security Module (LSM), das verbindliche Zugriffskontrolle über programmspezifische Profile durchsetzt, die in Form von Dateipfaden, Capabilities und Netzwerkprimitiven ausgedrückt werden, statt über die von SELinux verwendeten Inode-Labels. AppArmor entstand aus Immunix, wird von SUSE und Canonical gepflegt, ist seit Ende der 2000er-Jahre das Standard-MAC-Framework von Ubuntu und openSUSE und seit Version 2.6.36 Teil des Mainline-Kernels. Profile liegen unter /etc/apparmor.d und können im Modus enforce oder complain (nur Protokollierung) geladen werden, unterstützt von Werkzeugen wie aa-genprof, aa-logprof und aa-easyprof. Das pfadbasierte Design lässt sich in der Regel leichter schreiben und prüfen als SELinux-Richtlinien, allerdings um den Preis einer schwächeren Semantik bei Umbenennungen, Bind-Mounts und Chroots.

In Containern erzeugt und lädt Docker für jeden Container im Modus enforce ein docker-default-Profil in das tmpfs, sofern es nicht mit --security-opt apparmor= überschrieben wird; es blockiert Schreibzugriffe auf sensible Pfade wie /proc/sysrq-trigger und /sys und wirkt zusammen mit seccomp und entzogenen Capabilities als Defense-in-Depth. AppArmor wird außerdem von snapd, libvirt, LXD und Firefox genutzt. Seine Grenzen sind real: Da Regeln auf Pfade und nicht auf das zugrunde liegende Objekt passen, können Hardlinks und Mount-Tricks ein Profil mitunter umgehen, und ein Profil ist nur so gut wie seine Regeln – zu weit gefasste Globs (zum Beispiel das Zulassen von /** rwk) machen den ganzen Sinn zunichte. CVE-2019-5736 (das Überschreiben des runc-Host-Binaries) zeigte, dass Container-Ausbrüche in Bereichen auftreten können, die ein Standardprofil nicht abdeckt – weshalb AppArmor mit seccomp, User-Namespaces und Read-only-Mounts kombiniert und nicht allein darauf vertraut wird.

flowchart TB
  P[Prozessausführung] --> K[Kernel-LSM-Hook]
  K --> Q{Profil geladen?}
  Q -- No --> U[Nicht eingeschränkt: normales DAC]
  Q -- Yes --> M{Aktion im Profil?}
  M -- Modus enforce --> R{Erlaubt?}
  R -- Yes --> A[Zulassen]
  R -- No --> D[Verweigern + Audit-Log]
  M -- Modus complain --> L[Zulassen + Verstoß protokollieren]

Ein typischer Arbeitsablauf führt ein neues Profil im Modus complain aus, beansprucht die Anwendung im normalen Betrieb und nutzt anschließend aa-logprof, um die protokollierten Zugriffe in Regeln umzuwandeln, bevor auf enforce umgeschaltet wird.