Linux: AppArmor

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.

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.

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

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

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

# 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 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.

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.

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.

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/

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.

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.

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.

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.

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

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.

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.

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

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

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,
 
}

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

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

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.

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

Ü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

• Apparmor Wiki
• AppArmor
• Debugging AppArmor
• Application Confinement
• OpenSuse SDB: AppArmor Geeks
• OpenSuse: AppArmor Profile
• Novell Developer: AppArmor
• Launchpad: AppArmor
• Penguin Droppings: Application isolation with AppArmor (1)
• Penguin Droppings: Application isolation with AppArmor (2)
• Penguin Droppings: Application isolation with AppArmor (3)
• Penguin Droppings: Application isolation with AppArmor (4)