Objekt	Bedeutung
/ordner/datei	gilt für diese spezifische Datei datei in Verzeichnis /ordner
/ordner/*	gilt für alle Dateien im Verzeichnis /ordner
/ordner/a*	gilt für alle Dateien im Verzeichnis, die mit "a" beginnen
/ordner/*.png	gilt für alle Dateien mit der Endung .png
/ordner/[^.]*	gilt für alle Dateien in /ordner mit Ausnahme derjenigen, die mit einem "." beginnen
/ordner/	gilt für das spezifische Verzeichnis /ordner
/ordner/*/	gilt für jedes Verzeichnis in /ordner
/ordner/**	gilt für jede Datei oder jedes Verzeichnis in oder unterhalb von /ordner
/ordner/**/	gilt für jedes Verzeichnis in oder unterhalb von /ordnerordner/datei

Dateizugriffsberechtigungen

Option	Beschreibung
r	Lesezugriff ist erlaubt
w	Schreibzugriff ist erlaubt
a	Dateiinhalte können hinzugefügt werden
l	Es ist erlaubt, einen Link zu erstellen
k	Datei kann gesperrt werden (lockfile)
m	Es darf der Aufruf von mmap (memory map) erfolgen
x	Hilfsanwendung darf ausgeführt werden

Option	englisch für	Beschreibung
ux	unconfined execute mode	Hilfsanwendung ohne AppArmor-Überwachung ausführen
Ux	unconfined execute – scrub the environment	wie ux mit Bereinigen der Umgebung
ix	inherit execute mode	Hilfsanwendung erbt die Berechtigungen der Hauptanwendung
px	discrete Profile execute mode	setzt die Definition eines eigenen Profils für die Hilfsanwendung voraus
Px	Discrete Profile execute mode – scrub the environment	wie px mit Bereinigen der Umgebung
cx	Execute and transition to a child profile	Ausführen der Hilfsanwendung über ein Kind-Profil innerhalb des Profils der Hauptanwendung
Cx	Execute and transition to a child profile – scrub the environment	wie cx mit Bereinigen der Umgebung

Für die Ausführungsberechtigungen sind folgende Hinweise zu beachten

Die Benutzung von ux wird nicht empfohlen, sofern nicht unbedingt notwendig. Eine mit ux ausgeführte Hilfsanwendung wird von AppArmor nicht kontrolliert bzw. "eingesperrt" und kann somit u.U. eine erhebliche Lücke in ein ansonsten sicheres Profil der Hauptanwendung reißen.

Auch die Benutzung von Ux wird nicht empfohlen. Zwar wird hier ein sog. "environment scrubbing" 🇬🇧 durchgeführt (d.h. ein Bereinigen der Umgebung, indem Umgebungsvariable wie LD_PRELOAD entfernt werden). Ansonsten gilt jedoch dieselbe Problematik wie unter ux.

Erheblich sicherer ist die Verwendung von ix. Eine damit ausgeführte Hilfsanwendung erbt die Berechtigungen der Hauptanwendung, darf also nicht mehr, aber auch nicht weniger als diese. Dies kann problematisch sein, wenn die Hilfsanwendung mehr Rechte benötigt als die Hauptanwendung oder wenn die Rechte der Hilfsanwendung gezielt beschränkt werden sollen.

Erheblich flexibler ist diesbezüglich die Verwendung von px (bzw. Px). Voraussetzung ist, dass für die Hilfsanwendung ein eigenes AppArmor-Profil definiert ist, in dem die Berechtigungen deutlich von denen der jeweiligen Hauptanwendung abweichen können, und auf das auch andere Hauptanwendungen zugreifen können.

Noch flexibler ist die Verwendung von cx (bzw. Cx). Hier wird für die Hilfsanwendung ein lokales Profil innerhalb des Profils der Hauptanwendung angelegt. Der Vorteil gegenüber px ist, dass dadurch unterschiedliche Berechtigungen für die Hilfsanwendung festgelegt werden können, je nachdem, durch welche Hauptanwendung sie aufgerufen wird. Beispiel: Erstellt man z.B. ein AppArmor-Profil für den Browser Google Chrome, werden u.a. als Hilfsanwendungen xdg-open und xdg-settings benötigt, die über entsprechende Kind-Profile eingebunden werden können. Die Syntax für das Profil /etc/apparmor.d/opt.google.chrome.chrome sieht dann auszugsweise folgendermaßen aus: