AppArmor/HowTo

AppArmor/HowTo - Sicherheitsframework für Linux

Beschreibung

AppArmor ist ein Mandatory-Access-Control-(MAC)-Framework für Linux.

• Prozesse werden durch Profile eingeschränkt, die erlaubte Zugriffe auf Dateien, Verzeichnisse, Netzwerke und Fähigkeiten definieren.
• Auf Debian-basierten Systemen (z.B. Debian, Ubuntu) ist AppArmor typischerweise bereits installiert und beim Systemstart aktiv.
• AppArmor wird häufig als einfacher zu verwaltende Alternative zu SELinux eingesetzt.

Als Mandatory Access Control (MAC) System kontrolliert es Anwendungen einzeln

• Für diese können in Profilen Zugriffsrechte festgelegt werden, die feiner als die allgemeinen Dateirechte sind
• Neben den vordefinierten können eigene Profile aufgestellt werden
• Für jedes Profil kann einer von drei Eingriffs-Modi gesetzt werden

Zweck

Ziel ist die Begrenzung der Auswirkungen kompromittierter oder fehlerhafter Anwendungen.

• Typische Kandidaten sind Netzwerkdienste, Browser, Mail- und Büroanwendungen sowie Interpreter für potentiell unsichere Inhalte

Algorithmus

Ablauf (Kurzfassung)

1. Prüfen, ob AppArmor installiert und aktiviert ist
2. Netzwerkfähige Prozesse ohne Profil identifizieren
3. Profil für einen ausgewählten Dienst erzeugen (ggf. automatisch) und mit Log-Daten verfeinern
4. Profil in den passenden Modus (complain/enforce/audit) schalten.
5. Logs und ggf. Desktop-Benachrichtigungen auswerten
6. Optional weitere Profile hinzufügen bzw. vorhandene Profile anpassen

Installation

Seit vielen Jahren wird AppArmor auf Debian-basierten Systemen standardmäßig mitinstalliert.

• Falls Pakete fehlen, können diese nachinstalliert werden:

sudo apt install apparmor

Hilfsprogramme:

sudo apt install apparmor-utils apparmor-notify apparmor-profiles apparmor-profiles-extra

Tool	Beschreibung
apparmor-utils	Kommandozeilenwerkzeuge (aa-*)
apparmor-notify	Desktop-Benachrichtigung für AppArmor-Meldungen
apparmor-profiles	zusätzliche, vorkonfigurierte Profile
apparmor-profiles-extra	weitere, teilweise experimentelle Profile

Schutz durch AppArmor

AppArmor wird beim Systemstart geladen und aktiviert.

• Prozesse werden einem Profil zugeordnet, wenn ein dazu passender Regelsatz in /etc/apparmor.d/ vorhanden und geladen ist
• Ohne Profil arbeiten Prozesse nur mit klassischen Unix-Dateirechten, aber ohne zusätzliche MAC-Einschränkungen

AppArmor Utilities

• Weitere, detaillierte Utilities werden in der separaten Dokumentation zu Utilities behandelt

AppArmor-Modi (flags)

AppArmor kennt drei Hauptmodi pro Profil:

Modus	Beschreibung
complain	"Lernmodus". Regelverstöße werden geloggt, aber nicht blockiert.
enforce	"Zwangsmodus". Regelverstöße werden geloggt und blockiert.
audit	"Prüfmodus". alle Regelanwendungen und -verstöße werden geloggt.

Profile werden folgendermaßen umgeschaltet:

sudo aa-complain PROFIL   # Profil in den "complain"-Modus
sudo aa-enforce  PROFIL   # Profil in den "enforce"-Modus
sudo aa-audit    PROFIL   # Profil in den "audit"-Modus

Mehrere Profile gleichzeitig:

sudo aa-complain /etc/apparmor.d/*
sudo aa-enforce  /etc/apparmor.d/*

Hinweis

• Neue oder stark angepasste Profile zunächst im complain-Modus testen
• Nach Stabilisierung auf enforce umstellen
• audit ist sinnvoll für detaillierte Analysen, erzeugt aber viele Log-Einträge

Status prüfen

Hinweis

Alle Befehle zur Steuerung von AppArmor erfordern Root-Rechte (z.B. durch sudo)

AppArmor aktiviert

sudo aa-enabled

Typische Ausgabe:

• Yes – AppArmor ist aktiv.
• No – AppArmor ist deaktiviert bzw. das Kernel-Modul nicht geladen.

AppArmor Modi (flags)

AppArmor kennt drei Modi für jedes einzelne Profil

Modus	Beschreibung
complain	"Lernmodus": Aktionen, die gegen die Regeln verstoßen, werden nur geloggt und nicht verboten Das Profil enthält die Kennzeichnung flags=(complain)
enforce	"Zwangsmodus": Aktionen, die gegen die Regeln verstoßen, werden geloggt und verboten Das Profil enthält die Kennzeichnung flags=(enforce)
audit	"Prüfmodus": Alle Regelanwendungen und Regelverstöße werden geloggt Das Profil enthält die Kennzeichnung flags=(audit)

Profile werden somit folgendermaßen geladen

sudo aa-complain PROFIL # für den "Complain"-Modus
sudo aa-enforce PROFIL # für den "Enforce"-Modus
sudo aa-audit PROFIL # für den "Audit"-Modus 

Möchte man alle Profile auf einmal aktivieren, so geschieht dies mit diesem Befehl

sudo aa-complain /etc/apparmor.d/* # für den "Complain"-Modus"
sudo aa-enforce /etc/apparmor.d/* # für den "Enforce"-Modus 

Das Logging erfolgt dabei sowohl in der Syslog /var/log/syslog als auch in erweiterter Form in der Kernel-Log /var/log/kern.log

• Die /var/log/syslog ist dabei jedoch standardmäßig die ausschlaggebende, die auch von den AppArmor-Utils aa-logprof und aa-genprof benutzt wird

Möchte man sich von Hand anschauen, was AppArmor loggt, eignet sich tail durch Ausführung von

tail -F /var/log/syslog | grep "apparmor"

bzw

tail -F /var/log/kern.log | grep "apparmor"

[1]

Die Regelsätze befinden sich im Verzeichnis /etc/apparmor.d/

• Die Regeln haben dabei die Struktur "pfad.zur.datei.dateiname"
• Es ist also der Dateipfad enthalten, allerdings durch einen Punkt anstatt eines Slashs getrennt, der letzte Teil gibt den Namen des Programms/Dienstes/ an

Deaktivieren und Reaktivieren

Die Steuerung von AppArmor erfolgt als Dienst

• Um diesen komplett zu stoppen, dient nicht wie bei anderen Diensten üblich der Befehl stop, dieser leert nur den Cache
• Um AppArmor komplett zu stoppen, muss der folgende Befehl eingegeben werden

sudo aa-teardown

Der Neustart inkl. Laden alle aktiven Profile erfolgt mit

sudo systemctl reload apparmor.service

AppArmor Notify

Hat man das Paket aa-notify installiert, kann man die Benachrichtigung für DENIED-Messages aktivieren

• Dazu dient folgender Befehl im Terminal[2]

aa-notify -p

Die Benachrichtigung kann man testen mit

sudo tcpdump -i enp0s31f6 -n -s 0 -w /foo

(enp0s31f6 ist das Tcpip-Interface, das man mit ifconfig findet)

Profile bearbeiten

Grundsätzlich ist es möglich, von Hand bestehende Profile zu bearbeiten oder neue zu erstellen

• Es handelt es sich um normale Textdateien

Achtung

Wer das Editieren von Hand beabsichtigt, sollte genau wissen, was er tut! Es besteht eine erhöhte Gefahr, dass das Programm, welches durch das editierte Profil gesichert ist, entweder nicht mehr ausreichend gesichert ist oder auch, dass die Sicherung zu restriktiv ist, so dass das Programm nicht mehr richtig ablaufen kann!

Profilaufbau

Eine Profil-Datei ist dabei prinzipiell wie folgt aufgebaut

vergrößern

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <tunables/global> /pfad/zur/anwendung { #include <abstractions/base> [...] capability sys_admin [...] # Kommentar /usr/lib/gconv/** r /proc/meminfo r /bin/basename rmix [...] }

• Mit dem Befehl #include können andere (grundlegende) Regelsätze eingebunden werden
• In allen Profilen ist grundsätzlich die Datei /etc/apparmor.d/tunables/global mit #include eingebunden, die wiederum weitere Dateien aus diesem Verzeichnis enthält, in denen u.a. Variablen wie @{HOME} (für alle Homeverzeichnisse) oder @{PROC} (für das Verzeichnis /proc/) definiert sind
• Nach der Angabe des Pfades zur Anwendung, für die das Profil erstellt ist, stehen sämtliche Regeln innerhalb von geschweiften Klammern
• Jede Zeile endet mit einem Komma - mit Ausnahme von Kommentaren, #include-Anweisungen, mit denen sogenannten abstractions eingebunden werden, und Kind-Profile (näheres dazu weiter unten)
• Mit dem Befehl capability XYZ werden grundlegende Eigenschaften/Merkmale definiert
• Siehe dazu die entsprechende Manpage sowie Capability rules
• /PFAD/ZU/DATEI OPTION setzt die Berechtigungen für das jeweilige Verzeichnis bzw. die jeweilige Hilfsanwendung
• Dabei ist die Verwendung des Jokers * erlaubt, zwei ** bedeuten "inkl. aller Unterverzeichnisse" (extended globbing)
• Beispiele dazu

/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 /ordner

Weitere Hinweise und Details finden sich unter File Globbing

Berechtigungen

Grundsätzlich gilt: Eine Anwendung mit AppArmor-Profil darf nur, was im Profil durch entsprechende Regeln explizit erlaubt wird

• Wenn beispielsweise in einem Profil keine Lese- oder Schreib-Regel für das Home-Verzeichnis existiert, wird jeglicher Zugriff der betreffenden Anwendung auf dieses Verzeichnis blockiert

Attribute

Darüber hinaus gibt es drei zusätzliche Attribute

Attribut	Beschreibung
audit	alle Anwendungen der Regel werden grundsätzlich geloggt
owner	Berechtigung wird nur erteilt, wenn die Datei bzw. das Verzeichnis im Besitz des Benutzers ist
deny	der Zugriff auf die Datei bzw. das Verzeichnis wird explizit verboten

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	audit deny @{HOME}/.config/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

Dateizugriffsberechtigungen in AppArmor-Profilen
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 erfolgen
x	Hilfsanwendung darf ausgeführt werden

Die Option x kann nur in den folgenden Kombinationen verwendet werden

Ausführungsberechtigungen in AppArmor-Profilen
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 beispielsweise 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:
  vergrößern

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:
  vergrößern

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.  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 (beispielsweise "... 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 etwa 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

Generelle Hinweise zur Profilbearbeitung

Das manuelle Editieren eines AppArmor-Profils sollte die Ausnahme darstellen

• In der Praxis erfolgt das Hinzufügen von Regeln zu einem Profil mit Hilfe von aa-logprof
• Eine manuelle Nachbearbeitung beschränkt sich daher im wesentlichen auf drei Fälle:

1. Es sollte überprüft werden, ob man nicht mit aa-logprof versehentlich die gefährlichen Ausführungsmodi ux und Ux gewählt hat
2. Es macht bei umfangreichen Profilen u.U. Sinn, zum Zwecke einer besseren Übersichtlichkeit die Regeln zu gruppieren bzw. anders zu sortieren oder auch ggfs. einzelne Regeln mit einer zusätzlichen Kommentarzeile (beginnend mit einem #) zu erläutern
3. Es ist zu überprüfen, ob möglicherweise einzelne Regeln nachträglich modifiziert werden sollten, beispielsweise indem eine generelle Lese- und Schreibberechtigung für das Homeverzeichnis durch "deny"-Regeln für einzelne Unterverzeichnisse/Dateien eingeschränkt wird

Generell nicht manuell bearbeitet werden sollten die mit Ubuntu standardmäßig mitgelieferten und mit apparmor-profiles zusätzlich installierten Profile in /etc/apparmor.d, da alle Modifizierungen (auch über aa-logprof) bei einem Update dieser Profile über die Paketverwaltung verloren gehen

• Für diesen Zweck stehen stattdessen in /etc/apparmor.d/local jeweils leere "Unterprofile" zur Verfügung, die mit "#include" in das zugehörige Profil eingebunden sind
• Alle hier manuell hinzugefügten Berechtigungen oder "deny"-Regeln bleiben bei einem Update des betreffenden Profils erhalten
• Diese Empfehlung gilt natürlich nicht für selbsterstellte Profile

Weitere Profile beziehen

Ubuntu bringt bereits für ein paar Programme Profile mit, wobei diese jedoch teilweise deaktiviert sein könnten

• Um nun weitere Profile zu beziehen kann man
• Pakete mit weiteren Regeln installieren (siehe Abschnitt Installation)
• fremde Profile übernehmen
• selber Profile selber erstellen

Es sollte aber bedacht werden, dass diese Regeln nicht blind übernommen werden sollen/können, sondern den individuellen Bedürfnissen angepasst werden müssen

Im Internet kursieren noch zahlreiche weitere Profile für AppArmor, doch es sollte immer überlegt werden, wie vertrauenswürdig die Quelle ist und wie kompetent im Erstellen von Profilen

• Außerdem sind diese Regeln meist nicht auf die eigenen Bedürfnisse angepasst, sondern müssen nachträglich feinjustiert werden
• Auch hier gilt, dass keine Profile blind übernommen werden sollten

Konfiguration

Verzeichnisstruktur

Globale und Systemeinstellungen sind in /etc/apparmor gespeichert

• Die Anwendungsprofile sowie mehrere vordefinierte Unterverzeichnisse befinden sich in /etc/apparmor.d/
• Eine ausführliche Darstellung der Verzeichnisstruktur nebst Inhalten ist unter Policy Layout verfügbar

disable und force-complain

Enthält /etc/apparmor.d/disable eine Verknüpfung zu einem Profil, so wird dieses nicht automatisch geladen. Ähnlich sorgen Verknüpfungen unter /etc/apparmor.d/force-complain dafür, dass Profile nur im complain-Modus geladen werden (siehe unten)

Anhang

Dokumentation

Man-Page

Info-Page

Links

Projekt

1. AppArmor
   • Wiki
   • Dokumentation
   • FAQ

Weblinks

1. https://wiki.ubuntuusers.de/AppArmor/
2. AppArmor-Übersichtsseite Im englischen Ubuntu-Wiki
3. Using AppArmor Eintrag im englischen Wiki der Ubuntu-Community
4. AppArmor mit Ubuntu nutzen- Einführung von Kai Raven