Linux: AppArmor

Einleitung

AppArmor ist ein Modul des Linux Security Modules (LSM) Sicherheitsrahmenwerks, das für einzelne Anwendungen über das AppArmor Kernelmodul, AppArmor Anwendungrichtlinien (Anwendungsprofile) und das securityfs Dateisystem Zugriffsrechte auf Dateien und Verzeichnisse, Netzwerk Berechtigungen und Rechte für root Privilegien („capabilities“) mit Regeln beschränkt bzw. reguliert. AppArmor zählt zu den Mandatory Access Control (MAC) Sicherheitssystemen zur Kontrolle von Zugriffsrechten, wobei zuerst die Kontrolle der Benutzer- und Zugriffsrechte des Linux Discretionary Access Control (DAC) Sicherheitssystems angewendet wird, bevor die AppArmor Berechtigungsregulierung greift.

AppArmor dient primär der Absicherung von Prozessen mit Netzwerkzugriff und den von ihnen aufgerufenen Prozessen. Es können aber genauso gut andere Anwendungen reguliert werden, die lokal in ihren Berechtigungen beschränkt werden sollen.

Die Angaben und Informationen beziehen sich auf Ubuntu. Da AppArmor von den Entwicklerteams des Linux-Kernels, als auch von den Entwicklerteams der Linux-Distributionen ständig weiterentwickelt wird und die AppArmor Funktionen und Fähigkeiten u. U. von den Distributionen im unterschiedlichen Umfang umgesetzt werden, empfielt sich das Studium apparmor.d Man-Page und der darin verlinkten weiteren AppArmor Man-Pages, sowie der AppArmor Dokumentation im Linux Kernel Wiki, denn die sonstige AppArmor Dokumentation ist entweder hoffnungslos veraltet oder sehr dürftig.

Die Informationen über AppArmor gehen nicht auf die Verwendung der change_hat Subprofile und des AppArmor PAM Moduls ein.

Kernel Konfiguration

CONFIG_AUDIT y
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_PATH=y
CONFIG_SECURITY_APPARMOR y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE 1
CONFIG_SECURITY_APPARMOR_UNCONFINED_INIT=y
CONFIG_SECURITY_APPARMOR_HASH=y
CONFIG_DEFAULT_SECURITY_APPARMOR=y
CONFIG_DEFAULT_SECURITY="apparmor"

In einem Ubuntu Standard-Kernel sind die enstsprechenden Optionen für AppArmor bereits gesetzt. Neben AppArmor ist außerdem Yama aktiv, während die SELinux und Simplified Mandatory Access Control Kernel (Smack) LSM Module aktiviert sind, aber nicht ohne Weiteres angewendet werden, da AppArmor als Standard LSM definiert ist.

Grub

Zur dauerhaften Aktivierung von AppArmor:

/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="apparmor=1 security=apparmor"

Will man AppArmor dauerhaft deaktivieren und ein anderes Sicherheitsmodul verwenden:

/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="apparmor=0 security=modulname"

Danach wird Grub aktualisiert:

sudo update-grub

AppArmor Installation

Das AppArmor Sicherheitsrahmenwerk und das Kernelmodul ist je nach Konfiguration des Kernels (s. o.) bereits Bestandteil des Kernels. Falls der AppArmor Parser, die Utilities und Bibliotheken noch nicht installiert sind:

sudo aptitude install apparmor apparmor-utils

Einen Satz bereits vordefinierter, u. U. nicht angepasster oder veralteter Anwendungsprofile, die in das /etc/apparmor.d/ Verzeichnis installiert und damit von AppArmor verwendet werden, erhält man mit den apparmor-profiles, apparmor-profiles-extra Paketen.

sudo aptitude install|download apparmor-profiles apparmor-profiles-extra

Für die Verwendung des aa-easyprof Utility können zusätzliche Vorlagen installiert werden, die dann neben den bereits mit AppArmor mitgelieferten Vorlagen in /usr/share/apparmor/easyprof/ liegen.

sudo aptitude install|download apparmor-easyprof

AppArmor Utilities

aa-audit Anwendungsprofil in den Audit-Modus versetzen
aa-autodep erstellt für eine neue Anwendung ein Basis-Anwendungsprofil mit Complain-Modus und ohne Regeln
aa-cleanprof entfernt aus Anwendungsprofilen redundante Regeln, Kommentare und reorgansiert die Regelanordnung
aa-complain Anwendungsprofil in den Complain-Modus versetzen
aa-decode Dekodiert Hex-kodierte Strings in Log-Dateien
aa-disable Anwendungsprofil deaktivieren und entladen
aa-easyprof Anwendungsprofile mittels abstrakter Richlinien- und Anwendungs-Vorlagen erstellen
aa-enforce Anwendungsprofil in den Enforce-Modus versetzen
aa-exec eine Anwendung mit den Regeln bzw. Beschränkungen eines Anwendungsprofils (einer anderen Anwendung) ausführen
aa-genprof erstellt für eine neue Anwendung zuerst mit aa-autodep ein Basis-Anwendungsprofil, das dann nach Auswertung der Zugriffe und Berechtigungen im Logfile interaktiv vom Benutzer mit entsprechenden Regeln ausgestattet wird
aa-logprof Scan des Logfiles, in dem Regelabweichungen geloggt werden, anschließend interaktive Abfrage zur Veränderung bzw. Aufnahme neuer Berechtigungen in Anwendungsprofile
aa-status siehe apparmor_status
aa-unconfined überprüft mit netstat -nlp und wirft alle Prozesse aus, die einen TCP oder UDP Port geöffnet haben, für die kein Anwendungsprofil geladen ist
aa-update-browser listet die verfügbaren Abstraktionen für Browser Anwendungsprofile auf und modifiziert bestehende Browser Anwendungsprofile, um die Abstraktionen zu integrieren
apparmor_parser u. a. Anwendungsprofil in Kernel laden, ersetzen, neu hinzufügen, aus Kernel entfernen, Syntax prüfen
apparmor_status Information, ob AppArmor Kernelmodul geladen ist und welche Profile in welchem Modus für welche Anwendungen aktiv sind

AppArmor Profile

Für jede Anwendung, die mit AppArmor reguliert wird, befindet sich im Verzeichnis /etc/apparmor.d/ ein Anwendungsprofil, das als Anwendungsrichtlinie alle AppArmor Regeln enthält.

/etc/apparmor.d/absoluter.pfad.zu.anwendungsname

Profilaufbau

# Variablen
@{VARNAME1} = Wert

#include <tunables/name>

/absoluter/pfad/anwendungsname [flags=(kennzeichen)] {
 #include <abstractions/name>

 # ein Kommentar

 # Regeln für root Privilegien
 [regelattribut] capabilites root-berechtigung,

 # Regeln für Netzwerk Berechtigungen
 [regelattribut] network netzwerkprotokollfamilie netzwerktyp, oder
 [regelattribut] network tcp|udp|icmp,

 # Regeln für Datei- und Verzeichnis Berechtigungen
 [regelattribut] /pfade/ verzeichnis-rechte,
 [regelattribut] /pfade/datei(en) datei-rechte,
 # mit tunables Variable
 [regelattribut] @{VARNAME2}/[datei(en)] verzeichnis-/datei-rechte 

}

Variablen

Variablen können direkt in einem Anwendungsprofil definiert werden - dann gelten sie auch nur für diese Anwendung und ihr Anwendungsprofil oder sie werden alle Anwendungsprofile übergreifend in tunables Dateien definiert.

AppArmor Modi (flags)

Mit Kennzeichen, die in flags=( ) eingefügt werden, kann AppArmor dazu veranlasst werden, ein Profil in einen bestimmten Modus zu versetzen. Die Hauptmodi sind der Enforce, Complain und Audit Modus.

Im Enforce-Modus werden alle Regeln zwingend angewendet, während Regelabweichungen geloggt werden. Der Enforce-Modus benötigt, da er der Standard-Modus ist, keine flags=(enforce) Kennzeichnung. Mit sudo aa-enforce /etc/apparmor.d/profil.name wird ein Anwendungsprofil, das sich in einem anderen Modus befindet, in den Enforce-Modus versetzt.

Im Complain-Modus, der auch als Lern-Modus bezeichnet wird, werden alle Regeln – bis auf explizite deny … Regeln – nicht angewendet, d. h. eine Anwendung läuft so, als würde es keine AppArmor Regulierung (bis auf erwähnte deny Regeln) geben, aber Regelabweichungen werden ebenfalls geloggt. Für den Complain-Modus erhält das Anwendungsprofil die flags=(complain) Kennzeichnung. Mit sudo aa-complain /etc/apparmor.d/profil.name wird ein Anwendungsprofil, das sich in einem anderen Modus befindet, in den Complain-Modus versetzt. Der Complain-Modus bietet sich zwischenzeitlich oder nachträglich an, wenn Regeln im Enforce-Modus Funktionen der Anwendung blockieren, aber nicht geloggt werden bzw. sich geänderte oder zusätzliche Funktionen ergeben, um über die Beobachtung und Auswertung der Logausgaben mit sudo aa-logprof ein Anwendungsprofil zu erweitern oder zu aktualisieren.

Zusätzlich kann ein Anwendungsprofil mit flags=(audit) zwecks Beobachtung der gesamten Richtlinie in den Audit-Modus versetzt werden, in dem alle (positiven) Regelanwendungen und Regelabweichungen geloggt werden.

include Anweisung

In eine Profildatei können über include Anweisungen bereits definierte Variablen, Pfad-Aliase und Rechtevergaben eingebunden werden, um mehr oder weniger umfangreiche, aber gleichbleibende Definitionen in unterschiedliche bzw. viele Anwendungsprofile einfach einzubinden.

tunables

Dateien im /etc/apparmor.d/tunables/ Verzeichnis enthalten Variablen wie z. B. @{HOME} für alle /home/benutzer/ Verzeichnisse. Die Definition einer Variable kann weitere, bereits definierte Variablen enthalten. Außerdem können in einer tunables Datei mit #include <tunables/datei> oder #include <tunables/verz> weitere einzelne tunables Dateien oder alle tunables Dateien eines Verzeichnisses eingebunden werden.

Beispiel:

/etc/apparmor.d/tunables/home
@{HOME}=@{HOMEDIRS}/*/ /chroot/
@{HOMEDIRS}=/home/
 
#include <tunables/home.d>
/etc/apparmor.d/tunables/home
/etc/apparmor.d/home.d/otherhomes

In der /etc/apparmor.d/tunables/alias Datei können mit Pfad-Aliasen absolute Pfadangaben auf andere Pfade umgeleitet werden. Aliase werden nach Auswertung aller anderen Variablen angewendet.

Beispiel:

/etc/apparmor.d/tunables/alias
alias /pfad/verz/ -> /neuer_pfad/neues_verz/

abstractions

Dateien im /etc/apparmor.d/abstractions/ Verzeichnis enthalten Listen, in denen die bereits oben angesprochenen Zugriffsrechte auf Dateien und Verzeichnisse, Netzwerk Nutzungsrechte und Rechte für priviligierte Berechtigungen („capabilities“) vordefiniert sind. Außerdem können in einer abstractions Datei die Variablen (@{VARNAME}) der tunables Dateien und mit #include <abstractions/datei> andere abstractions Dateien, d. h. deren Rechtedefinitionen eingebunden werden.

Beispiel:

/etc/apparmor.d/abstractions/ubuntu-konsole
  #include <abstractions/consoles>
  #include <abstractions/kde>
  capability sys_ptrace,
  @{PROC}/[0-9]*/status r,
  @{PROC}/[0-9]*/stat r,
  @{PROC}/[0-9]*/cmdline r,
  /var/run/utmp r,
  /dev/ptmx rw,
  /usr/bin/konsole ix,

Mit einer Distribution werden neben bereits vordefinierten Profildateien für bekannte Anwendungen auch eine ganze Reihe vordefinierter tunables und abstactions Dateien für die include Anweisungen ausgeliefert.

Die include Anweisungen kann man zur Vereinfachung und Erleichterung bei der Gestaltung von Anwendungsprofilen verwenden, man muss es aber nicht. Stattdessen kann auch jede Berechtigung für jede einzelne Ressource selbst definiert werden, was zu sehr komplexen und umfangreichen Profildateien führen kann. Andererseits sollte man bei Nutzung der include Anweisungen wissen, welche Berechtigungen mit ihnen verbunden sind und man muss sich auf korrekte, d. h. sichere Definitionen in den vorgefertigten include und Profildateien der Distribution verlassen.

Zum Beispiel enthält AppArmor 2.5.1 die multimedia Abstraktion für Webbrowser, in der die Regel owner @{HOME}/.macromedia/** rw, steht, was zum Ausführen von Flash-Inhalten nicht nötig ist, aber die ggf. ungewollte Speicherung von „Flash-Cookies“ ermöglicht.

Bei der Erstellung eigener Anwendungsprofile erhält man während des Abfrageprozesses die Möglichkeit, entweder vorgeschlagene include Anweisungen oder speziellere und eigene Regeln in ein Profil aufzunehmen zu lassen.

Ändert man im laufenden Betrieb Abstraktionen oder hat neue Abstraktionen hinzugefügt, sollte man danach AppArmor neu starten.

Regeln

Attribute

Mit den Attributen audit, deny, wird eine Regel näher bestimmt oder ihre Auswertung durch AppArmor beeinflusst. Ist kein Attribut vor einer Regel angegeben, wird die Berechtigung erteilt.

Attribut Erklärung
audit Überwache und logge alle Anwendungen der Regel
deny Verbiete die Berechtigungen
owner Erlaube Berechtigung nur dann, wenn sich die Datei oder Verzeichnis im Besitz des Benutzers / Prozesses befindet

Das audit Attribut kann mit deny oder owner kombiniert werden, z. B. „audit owner Regel“ und das deny mit dem owner Attribut. Da jede Richtlinie eine Whitelist darstellt, d. h. nur das, was mit Regeln definiert wurde, ist erlaubt und alles, was nicht mit Regeln erlaubt wurde, gilt eh als verboten, sind Verbots-Regeln mit deny Attribut eigentlich nicht notwendig. Das Setzen von deny Regeln speichert jedoch einmal gesetzte Verbote, was erneute Abfragen zur Gewährung einer Berechtigung bzw. Anfragen der Anwendung auf Gewährung einer Berechtigung unterbindet.

Capabilities

Benötigt bzw. fordert ein unpriviligierter Prozess die Gewährung von Berechtigungen an, die ansonsten nur priviligierten Prozessen, d. h. nur root und „als root“ laufender Prozesse zustehen („capabilities“), kann AppArmor die Gewährung einzelner priviligierter Berechtigungen an den Prozess vermitteln oder verwehren, indem die Berechtigung einfach nicht in der Richtlinie aufgeführt (siehe Whitelist) oder explizit mit deny verboten wird.

Beispiel:

deny capability sys_ptrace,
capability mknod,

Da die Gewährung eines zu großen Umfangs an priviligierter Berechtigungen oder der falschen Berechtigungen die Sicherheit des Systems beeinträchtigen bzw. die AppArmor Absicherung wieder aufweichen kann, sollten Gewährungen äußert sorgsam und sparsam erfolgen.

Da weitere Erläuterungen zum System der Capabilties zu weit führen würde, sei hier auf die capabilities Man-Page, Zugriffsrechte über File-Capabilities regeln, Grünes Licht für Pcaps, POSIX Capabilities & File POSIX Capabilities und False Boundaries and Arbitrary Code Execution verwiesen.

Ptrace, Signale, Sockets und D-Bus

Ptrace

Allgemein und verkürzt zusammengefasst, betreffen ptrace Regeln die Berechtigung für eine Anwendung, verschiedene Prozessinformationen einer andereren Anwendung auszulesen und zu verfolgen („tracen“) bzw. die Erteilung der Berechtigung an eine andere Anwendung, dass die eigenen Prozessinformationen ausgelesen und verfolgt werden. Die ptrace Regeln sind in zwei Gruppen von Berechtigungen unterteilt:

  • Die trace und tracedby Berechtigungen betreffen die Untersuchung/Kontrolle der Prozessausführung und des Prozessspeichers per ptrace Systemaufruf.
  • Die read und readby Berechtigungen betreffen das Auslesen von Einträgen und Inhalten im /proc Dateisystem, von Futex-Informationen, Informationen per kcmp Systemaufruf (für CRIU bzw. CONFIG_CHECKPOINT_RESTORE=y wie im Standard-Ubuntukernel) und aus Performance Traces.

In der /etc/apparmor.d/abstractions/base Abstraktion wurden ab Ubuntu 14.04 zwei ptrace Regeln global für alle Anwendungen definiert, die durch AppArmor reguliert werden und die base Abstraktion mit #include <abstractrions/base> in ihrer AppArmor Richtlinie einbinden:

/etc/apparmor.d/abstractions/base
ptrace (readby),
ptrace (tracedby),


Zusammengefasst hätten die Regeln auch als „ptrace (readby, tracedby),“ formuliert werden können. Das bedeutet, die Prozessinformationen jeder AppArmor regulierten Anwendung können durch alle Anwendungen, die nicht durch AppArmor reguliert werden („unconfined“) und durch alle Anwendungen mit AppArmor Regulierung bzw. Richtlinie vollständig auf den oben genannten Wegen ausgelesen und verfolgt werden. Für die erteilte „ptrace (tracedby),“ Berechtigung muss allerdings analog die „ptrace (trace),“ Berechtigung (neben der „capability sys_ptrace,“ Berechtigung) in den AppArmor Richtlinien der Anwendungen existieren, die ptrace Systemaufrufe erteilen sollen.

Das bedeutet weiter, dass für alle Anwendungen, die auch die Anwendungen mit AppArmor Richtlinie per „ptrace“ Berechtigungen „untersuchen“ können sollen, eigene AppArmor Richtlinien zu erstellen sind. Das Gleiche gilt für alle Anwendungen, die man mit AppArmor Richtlinien generell vom „Zugriff“ seitens anderer Anwendungen mittels „ptrace“ Berechtigungen isolieren will.

Wenn man sich von den Vorgaben der base Abstraktion lösen will, wird die base Abstraktion nicht verwendet bzw. die #include <abstractions/base> Einbindung aus der Richtlinie entfernt. Einzelne, benötigte Regeln in der base Abstraktion müssen dann in die AppArmor Richtlinien übernommen werden. Anschließend reguliert man die read und/oder trace Berechtigungen und Zugriffe selektiv.

Mit dem peer Parameter wird dabei entweder der absolute Pfad der Anwendung angegeben, die durch eine AppArmor Richtlinie reguliert wird und „ptrace“ Berechtigungen ausübt bzw. erteilt oder der Wert unconfined, der – wie bereits oben angegeben wurde – als Platzhalter für alle Anwendungen steht, die nicht durch AppArmor reguliert sind.

Für eine Anwendung, die trace und/oder read Berechtigungen erhalten und auf alle Prozesse ausüben soll, setzt man in deren Richlinie:

/etc/apparmor.d/absoluter.pfad.anwendung
  ptrace (read, trace), # oder
  ptrace (read), # oder
  ptrace (trace),


Für eine Anwendung, die vor trace und/oder read Zugriffen durch Anwendungen außerhalb der AppArmor Regulierung und mit eigener AppArmor Richtlinie geschützt werden soll, setzt man in die Richtlinie der ersten Anwendung mit dem bereits bekannten deny Attribut als Präfix:

/etc/apparmor.d/pfad.mein.browser
  # alle Anwendungen ohne AppArmor Regulierung:
  deny ptrace (readby, tracedby) peer=unconfined,
 
  # Anwendung mit AppArmor Richtlinie:
  deny ptrace (readby, tracedby) peer=/absoluter/pfad/anwendung,
 
  # Browser soll generell keine ptrace Berechtigungen besitzen:
  deny ptrace (read, trace),


Für eine Anwendung, die für read und/oder trace Zugriffe durch eine andere Anwendung mit eigener AppArmor Richtlinie zugänglich sein soll, setzt man in die Richtlinie der ersten Anwendung:

/etc/apparmor.d/absoluter.pfad.anwendung
  # Anwendung mit trace/read Berechtigung in eigener AppArmor Richtlinie:
  ptrace (readby, tracedby) peer=/absoluter/pfad/anwendung,
  ptrace (readby, tracedby) peer=/usr/sbin/unhide-linux,


Man kann auch alle Anwendungen mit oder ohne trace und/oder read Berechtigung in eigene Abstraktionen zusammenfassen:

/etc/apparmor.d/abstractions/tracer
  ptrace (readby, tracedby) peer=/absoluter/pfad/anwendung1,
  ptrace (readby, tracedby) peer=/usr/sbin/unhide-linux,
  ptrace (tracedby) peer=/absoluter/pfad/anwendung3,
/etc/apparmor.d/abstractions/notracer
  deny ptrace (readby, tracedby) peer=unconfined,
  deny ptrace (readby, tracedby) peer=/absoluter/pfad/anwendung1,
  deny ptrace (tracedby) peer=/absoluter/pfad/anwendung2,


und diese dann in einzelnen AppArmor Richtlinien einbinden:

/etc/apparmor.d/pfad.mein.browser
  #include <abstractions/tracer>
  # und/oder
  #include <abstractions/notracer>
Signale und Unix Domain Sockets

Signale

Die Signal-Regeln betreffen die Berechtigung für Prozesse anderen Prozessen Signale wie z. B. SIGTERM zur Prozess-Beendigung zu senden („send“) und für den empfangenden Prozess die Berechtigung, Signale anderer Prozesse entgegenzunehmen („receive“).

In der /etc/apparmor.d/abstractions/base Abstraktion wurden ab Ubuntu 14.04 drei Signal-Regeln global für alle Anwendungen definiert, die durch AppArmor reguliert werden und die base Abstraktion mit #include <abstractrions/base> in ihrer AppArmor Richtlinie einbinden:

/etc/apparmor.d/abstractions/base
  signal (receive) peer=unconfined,
  signal peer=@{profile_name},
  signal (receive, send) set=("exists"),


Die vorletzte Regel besagt nur, dass ein Prozess sich selbst signalisieren kann und die letzte Regel das gegenseitige Senden und Empfangen von Informationen zur Existenz der Prozesskennung (PID).

Die erste Regel erteilt die Berechtigung bzw. „Empfangsbereitschaft“ für alle Anwendungen, die durch AppArmor reguliert werden, alle Signale von Anwendungen zu erhalten, die nicht durch AppArmor reguliert sind. Die erste Regel ist z. B. für alle Dienste und Anwendungen mit AppArmor Richtlinie notwendig, die durch Skripte und Steuerungsanwendungen kontrolliert werden, denn ansonsten müssten auch für sie AppArmor Richtlinien existieren oder konstruiert werden.

Unteinander können AppArmor regulierte Anwendungen bis auf die PID-Informationen zunächst keine Signale senden und empfangen, da in der base Abstraktion nicht die allgemeine und sicherheitsmäßig nicht zu empfehlende signal (receive, send), Regel steht bzw. sie nur Signale senden und empfangen können, wenn mit dem bereits genannten peer Parameter definiert wird, wer zu und von wem Signale senden und empfangen kann und mit dem set Parameter der Katalog der Signale bestimmt wurde.

Allgemein und zusammengefasst lautet die Regel-Syntax für Signal-Berechtigungen:

# allgemein/global:
signal (receive)|(send)|(receive, send)|(read)|(write),
signal (receive)|(send)|(receive, send) set=(signal1, signal2, signalN),

# allgemein/global bezogen auf Anwendungen mit AppArmor Richtlinie:
signal (receive)|(send)|(receive, send) peer=/absoluter/pfad/anwendung,
signal (read)|(write) peer=/absoluter/pfad/anwendung,

# allgemein/global bezogen auf Anwendungen ohne AppArmor Regulierung:
signal (receive)|(send)|(receive, send) peer=unconfined,
signal (read)|(write) peer=unconfined,

# explizit bezogen auf Anwendungen mit AppArmor Richtlinie:
signal (receive)|(send)|(receive, send) set=(signal1, signal2, signalN) peer=/absoluter/pfad/anwendung,


Mit dem deny Attribut als Präfix wie z. B. in deny signal (receive) set=(term), wird die Signal-Berechtigung verweigert.

Wenn man sich wie bei den ptrace Berechtigungen von den Vorgaben der base Abstraktion lösen bzw. einzelne Anwendungen explizit restriktiver regulieren will, kann man die beiden letzten Signal-Regeln aus der base Abstraktion in eine eigene Abstraktion überführen und diese dann einbinden oder die beiden Regeln direkt in die Richtlinie der jeweiligen Anwendung aufnehmen, also z. B.:

/etc/apparmor.d/abstractions/signal-genallow
  signal peer=@{profile_name},
  signal (receive, send) set=("exists"),
/etc/apparmor.d/pfad.mein.browser
  #include <abstractions/signal-genallow>


oder

/etc/apparmor.d/pfad.mein.browser
  signal peer=@{profile_name},
  signal (receive, send) set=("exists"),


Wenn man z. B. den Firefox Browser hinsichtlich Signale isolieren und/oder einschränken will, könnte man z. B. in seine AppArmor Richlinie setzen:

/etc/apparmor.d/pfad.mein.browser
  #include <abstractions/signal-genallow>
  deny signal (receive, send) set=(abrt, hup, int, stop, trap),
  deny signal (send) set=(kill, term),

Unix Domain Sockets

Neben den Signalen kann man auch die Interprozesskommunikation (IPC) zwischen Prozessen mittels Unix Domain Sockets regulieren bzw. unterbinden. Die einfachste Richtlinie für alle Anwendungen, die von der Verwendung von Sockets und IPC mit anderen Anwendungen abgeschnitten werden sollen, lautet schlicht

  deny unix,

Wird unter Debian nicht implementiert. Alternativ kann mit firejail reguliert werden.

Netzwerk Berechtigungen

Mit network Regeln wird einer Anwendung die Nutzung von Netzwerkprotokollfamilien und -typen gewährt oder verboten. Zur Vereinfachung die gebräuchlichsten „Internet“ Regeln:

IPv4 TCP, UDP
network inet stream,
network inet dgram,
IPv6 TCP, UDP
network inet6 stream,
network inet6 dgram,
TCP, UDP, ICMP unabhängig von der Netzwerkprotokollfamilie
network tcp,
network udp,
network icmp,

Bezeichnungen für weitere Netzwerkprotokollfamilien und -typen erhält man mit man apparmor.d. Wird in einem Anwendungsprofil #include <abstractions/nameservice> eingefügt, was AppArmor regelmäßig bei allen Netzwerk-Anwendungen vorschlägt, lauten die Regeln

network inet stream,
network inet6 stream,
network inet dgram,
network inet6 dgram,

Wird unter Debian nicht implementiert. Alternativ kann mit firejail reguliert werden.

Verzeichnis- und Datei-Berechtigungen

Bei der Angabe von Verzeichnis- und Dateinamen in Regeln können folgende AppArmor Wildcards und Platzhalter verwendet werden:

@{}[]^?* Sonderzeichen, die innerhalb von Datei- oder Verzeichnisnamen selbst mit \Z maskiert werden müssen
@{NAME}/ Variable für Verzeichnis (/verz)
? ein Zeichen außer /
[abc] / [a-c] ein Zeichen aus Zeichenklasse
[^abc] / [^a-c] keines der Zeichen aus Zeichenklasse
{string1,string2} String1 oder String2
* Keine oder beliebig viele Zeichen außer / und inklusive .
** Keine oder beliebig viele Zeichen inklusive / und .
/verz/ ein Verzeichnis selbst
/verz/datei eine einzelne Datei
/verz/* alle Dateien direkt im Verzeichnis
/verz/*/ alle Unterverzeichnisse direkt im Verzeichnis
/verz/** alle Dateien und Unterverzeichnisse irgendwo im Verzeichnis
/verz/**/ alle Unterverzeichnisse irgendwo im Verzeichnis
/verz** das Verzeichnis selbst plus alle Dateien und Unterverzeichnisse irgendwo im Verzeichnis

Hinter den Verzeichnis- und Dateiangaben folgt die Angaben einzelner und kombinierter Berechtigungen:

r read Verzeichnisinhalt und Datei lesen
w
a
write
append
Datei erstellen, löschen, in Datei schreiben oder
Dateiinhalte hinzufügen
m mmap Datei über mmap Aufruf als ausführbar in Speicher mappen
l link Datei als Link erstellen, Link auflösen
k Datei als Lockfile anlegen
ix inherit execute Datei mit den Berechtigungen des Anwendungsprofils der Hauptanwendung ausführen
z. B. für Hilfsanwendungen und Shells (cat, grep, rm, bash)
px profiled execute Datei mit den Brechtigungen des eigenen Anwendungsprofils in /etc/apparmor.d/ ausühren
Px wie px mit Sicherung der Umgebung
z. B. für Hilfsprogramme, auch standalone, aber nicht für Shells
ux unconfined execute Datei ohne AppArmor Überwachung bzw. Anwendungsprofil ausführen
Ux wie ux mit Sicherung der Umgebung ausführen
[C|c]x → profil_name child execute von Hauptanwendung aufgerufene Hilfsanwendung, die im Anwendungsprofil der Hauptanwendung ihr eigenes Profil mit dem Namen „profil_name“ erhält, um ihr weniger oder mehr Rechte als dem Hauptprogramm zu geben (statt ix, bei Cx mit Sicherung der Umgebung)
P|pix, C|cix px, Px, cx, Cx können mit i(x) kombiniert werden. Dann gelten als Fallback Lösung die Berechtigungen des Anwendungsprofils der Hauptanwendung für die auszuführende Datei, sollte das eigene oder Kind-Profil nicht existieren

Sicherung der Umgebung: vor Ausführung werden Umgebungsvariablen entfernt, d. h. die ausgeführte Anwendung findet eine leere Umgebung vor, was auch zum Nichtfunktionieren der aufgerufenen Anwendung führen kann.

Beispiel Cx: Hilfsanwendung mit eingebettetem Profil
/pfad/hauptanwendung {
 Berechtigungen,
 /pfad/hilfsanwendung Cx -> profil_name,
 
  profile profil_name {
    Berechtigungen,
 
  }
 
}
Beispiel Px: Anwendung mit eigenem Profil in /etc/apparmor.d/
/pfad/hauptanwendung {
 Berechtigungen,
 /pfad/anwendung Px,
 
}

Profil erstellen und ändern

Erstellen

1. Methode

  1. Anwendung beenden
  2. sudo tail -f -n 20 /var/log/messages
  3. sudo aa-genprof /pfad/anwendung startet die Profilerstellung
  4. Anwendung starten
  5. Alle Aktionen mit der Anwendung ausführen bzw. Anwendung Aktionen ausführen lassen
  6. Anwendung beenden
  7. aa-genprof mit (S)can die Logausgaben scannen lassen
  8. die aa-genprof Regelvorschläge prüfen, akzeptieren, ändern oder ablehnen
  9. aa-genprof mit (F)inish beenden und Profil speichern lassen
  10. sudo aa-status zur Prüfung, ob Profil angelegt wurde
  11. sudo aa-enforce|complain /etc/apparmor.d/profil.name falls Anwendungsprofil im Enforce- oder Complain-Modus laufen soll
  12. Anwendung starten

2. Methode

Man schaut sich die tunables und abstractions Regelprofile an und erstellt sich daraus eine Vorlage mit den Anweisungen, die vorläufig für alle neuen Anwendungen gelten können und zum eigenen System passen. Zum Beispiel:

#include <tunables/home>
#include <tunables/multiarch>
#include <tunables/proc>

/pfad/anwendung flags=(complain) {
  #include <abstractions/X>
  #include <abstractions/audio> (nur bei Audioausgabe)
  #include <abstractions/base>
  #include <abstractions/dbus>
  #include <abstractions/dbus-session>
  #include <abstractions/fonts>
  #include <abstractions/freedesktop.org>
  #include <abstractions/ibus>
  #include <abstractions/kde>
  #include <abstractions/private-files>
  #include <abstractions/private-files-strict> (nicht für Mozilla Anwendungen)
  #include <abstractions/ssl_certs> (bei Nutzung systemweit installierter CA-Zertifikate)
  #include <abstractions/user-download>
  #include <abstractions/user-tmp>

  capability mknod,

  deny network inet6 dgram,
  deny network inet6 stream,
  network inet dgram,
  network inet stream,

  deny @{HOME}/.{dir1,dirN}/ rwklm,

In der Vorlage setzt man den realen, absoluten Pfad zur Anwendung ein, ersetzt die Verzeichnis-Platzhalter in der letzten Zeile durch die Verzeichnisse, auf die die Anwendung zusätzlich keinen Zugriff erhalten soll und speichert sie als root unter /etc/apparmor.d/pfad.zur.anwendung. Danach beendet man die Anwendung und aktiviert das Profil mit:

sudo apparmor_parser -av /etc/apparmor.d/pfad.zur.anwendung

Anschließend wird das Profil über die Beobachtung der Logdateien bzw. mit sudo aa-logprof ergänzt und nach Aufnahme aller Regeln mit sudo aa-enforce in den Enforce-Modus versetzt.

Stößt man in den Logs auf Meldungen mit „name=alphanumerischerstring“ handelt es sich um Angaben zu Pfaden und Dateien, die von AppArmor Hex-kodiert wurden. Um den Hex-kodierten String zu dekodieren und die übersetzen Angaben in Regeln einzusetzen:

aa-decode alphanumerischerstring

Ändern

Danach das Verhalten der Anwendung und die Logausgaben beobachten. Bei Verboten oder Fehlfunktionen sudo aa-logprof ausführen, um nachträglich Regeln und Berechtigungen zu ändern bzw. zu vergeben, damit das Anwendungsprofil aktualisiert wird.

aa-genprof und -logprof Hotkeys

Aktionen und die jeweilige Taste (T) nach Anwendung von aa-genprof und aa-logprof:

(A)llow erlaube die in der ausgewählten Regel enthaltene Berechtigung
(C)hild siehe cx, Cx
(F)inish die Änderung eines Anwendungsprofils ab einem bestimmten Punkt beenden und nur die bis dahin geänderten oder neuen Regeln speichern
(G)lob ersetzt bei einem angezeigten Regelvorschlag schrittweise den letzten Teil einer Pfadangabe zuerst durch /*, dann durch /** (siehe AppArmor Wildcards)
Glob w/(E)xt siehe (G)lob, dabei wird datei.ext zuerst durch *.ext, bei weiterer Pfadverkürzung durch **.ext ersetzt
(I)nherit siehe ix (wird immer als rix eingetragen)
(N)ame siehe cx → profil_name, px → profilname mit Wahl zwischen cx oder px, Abfrage zur Sicherung der Umgebung und Name des Profils
(N)ew Eingabe einer selbstdefinierten Regel
(O)pts Audi(t) oder (O)wner: audit oder owner Attribut hinzufügen oder entfernen
(P)rofile siehe px, Px (wird immer mit px eingetragen)
Abo(r)t Abbruch ohne Speicherung / Aktualisierung des Profils
(S)can das Logfile nach AppArmor Meldungen scannen
(S)ave Changes gänderte oder neue Regeln im Anwendungsprofil speichern
(V)iew Changes Änderungen anzeigen lassen
(U)nconfined siehe ux, Ux
(X)ix siehe C|cix, P|pix

Kommandoübersicht

Übersicht über die Anwendungen / Prozesse mit geöffnetem TCP oder UDP Port, für die AppArmor Profile im Enforce-Modus (enforce) oder Complain-Modus (complain) existieren (confined) oder nicht existieren (not confined)

sudo aa-unconfined

Übersicht über alle aktiven Anwendungen / Prozesse

sudo aa-unconfined --paranoid

Status der AppArmor Profile: Wieviele Profile sind geladen, welche sind im Enforce- und im Complain-Modus

sudo aa-status

oder

sudo apparmor_status

Eine neues Profil erstellen

sudo aa-genprof /pfad/zur/anwendung

Profile interaktiv ändern / aktualisieren

sudo aa-logprof

Ein Profil in den Enforce-, Complain- oder Audit-Modus setzen

sudo aa-enforce profil.name
sudo aa-complain profil.name
sudo aa-audit profil.name

Ein Profil nach einer Änderung neuladen

sudo apparmor_parser -rv /etc/apparmor.d/profile.name

Neuladen eines Profils unter Umgehung des Profil-Cache, nachdem die Profildatei durch eine gleichnamige Datei ersetzt wurde

sudo apparmor_parser -T -rv /etc/apparmor.d/profile.name

Alle Profile neuladen

sudo systemctl reload apparmor

Ein Profil deaktivieren

sudo ln -s /etc/apparmor.d/profil.name /etc/apparmor.d/disable/
sudo systemctl reload apparmor

oder

sudo apparmor_parser -Rv /etc/apparmor.d/profile.name

Ein Profil löschen

sudo apparmor_parser -Rv /etc/apparmor.d/profile.name
sudo rm /etc/apparmor.d/profile.name

Verweise auf aktuelle Seite