Attribute¶

Darüber hinaus gibt es drei zusätzliche Attribute:

deny ist sinnvoll, wenn etwa für das Home-Verzeichnis Lese- und Schreibberechtigung durch eine entsprechende Regel erteilt wurde, aber besonders sicherheitskritische Verzeichnisse/Dateien geschützt werden sollen. Beispiel:

1
2

audit deny @{HOME}/.config/autostart/** wl,
audit deny @{HOME}/.kde{,4}/Autostart/** wl,

Netzwerkberechtigungen¶

AppArmor kann einer Anwendung den Netzwerkzugriff allgemein oder auch sehr spezifisch erlauben oder verbieten. Typische Beispiele:

1
2
3
4
5
6

network,                     # Netzwerkzugriff wird generell erlaubt
deny network,                # Netzwerkzugriff wird generell verboten 
network tcp,                 # TCP-Verbindungen werden erlaubt
network udp,                 # UDP-Verbindungen werden erlaubt
network inet stream,         # IPv4 TCP-Verbindungen werden erlaubt
network inet6 dgram,         # IPv6 UDP-Verbindungen werden erlaubt

Weitere Details unter Network rules 🇬🇧.

Dateizugriffsberechtigungen¶

In AppArmor gibt es folgende Berechtigungen:

Die Option x kann nur in den folgenden Kombinationen verwendet werden:

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:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

  # Last Modified: Sat Feb 16 18:28:03 2013 #include <tunables/global> /opt/google/chrome/chrome { [...] /opt/google/chrome/xdg-settings Cx, [...] /usr/bin/xdg-open Cx, /usr/bin/xdg-settings Cx, [...] profile /opt/google/chrome/xdg-settings { /bin/dash r, /bin/grep rix, /bin/readlink rix, [...] } profile /usr/bin/xdg-open { #include <abstractions/base> /bin/dash r, /etc/X11/cursors/oxy-white.theme r, [...] } profile /usr/bin/xdg-settings { /bin/cat rix, /bin/dash r, [...] } }

• Als weitere Variante mit cx und Cx ist eine sog. "named profile transition" möglich. Hier wird ein Kind-Profil namentlich explizit definiert. Sollen in dem obigen Beispiel keine separaten Kind-Profile für /opt/google/chrome/xdg-settings und /usr/bin/xdg-settings erstellt werden, könnte etwa ein gemeinsames Kind-Profil namens gemeinsame_xdg_settings definiert werden, auf das die Hilfsanwendungen mit einem Pfeilsymbol verweisen. Die Syntax ändert sich dann in:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  #include <tunables/global> /opt/google/chrome/chrome { [...] /opt/google/chrome/xdg-settings Cx -> gemeinsame_xdg_settings, [...] /usr/bin/xdg-settings Cx -> gemeinsame_xdg_settings, [...] profile gemeinsame_xdg_settings { /bin/dash r, /bin/grep rix, /bin/readlink rix, [...] } }

Ein weiteres interessantes Beispiel einer "named profile transition" enthält die abstraction /etc/apparmor.d/abstractions/ubuntu-browsers.d/java.

Abstractions¶

Im Verzeichnis /etc/apparmor.d/abstractions befinden sich eine Vielzahl von vorgefertigten Regelsätzen, den sog. "abstractions". Sie enthalten Regeln, die typischerweise bei der Erstellung eines AppArmor-Profils von vielen Anwendungen benötigt werden. Durch Einbinden über den "#include" - Befehl kann die Profilerstellung deutlich vereinfacht werden. Die jeweiligen abstractions werden - wenn benötigt - bei der Regelerstellung bzw. beim Optimierung des Profils mit aa-logprof angeboten. Folgende Hinweise sollten dabei beachtet werden:

• In vielen abstractions sind andere abstractions über #include eingebunden, und in diese wiederum oft andere abstractions. Durch diese mehrstufige Verschachtelung ist es - insbesondere bei der Verwendung mehrerer abstractions - häufig sehr schwierig, die effektiven Berechtigungen zu durchschauen, die man sich dadurch eingehandelt hat. Es besteht daher die Gefahr, dass auf diese Weise einer Anwendung mehr Rechte als nötig oder beabsichtigt erteilt werden. Das ist ein potentielles Sicherheitsrisiko.

• Hinzu kommt, dass es bei der Verwendung mehrerer abstractions mitunter zu konkurrierenden Berechtigungen kommen kann, was beim Laden des Profils mit einer entsprechenden Fehlermeldung (z.B. "... conflicting permissions...") quittiert wird.

• Aus diesen Gründen ist es ratsam, sich bei der Verwendung von abstractions in Zurückhaltung zu üben. Wird von aa-logprof eine spezifische Regel und als Alternative eine oder mehrere abstractions angeboten, sollte man die Regel bevorzugen, auch wenn dies die Profilerstellung etwas mühsamer macht.

• Nichtsdestotrotz sind eine Reihe von abstractions sehr sinnvoll. Da den meisten Anwendungen Lese- und Schreibzugriff auf das Homeverzeichnis gewährt werden muss, ist es z.B. sinnvoll, zur Absicherung sicherheitskritischer Dateien oder Verzeichnisse das Profil mit "#include <abstractions/private-files>" (oder u.U. in einer erweiterten Form mit "#include <abstractions/private-files-strict>") zu ergänzen.