* ''aa-logprof'' verarbeitet typischerweise Meldungen aus '''/var/log/syslog'''
* ''aa-logprof'' verarbeitet typischerweise Meldungen aus '''/var/log/syslog'''
* Für umfangreiche Analysen kann ''audit''-Modus sinnvoll sein, erhöht aber Log-Volumen deutlich
* Für umfangreiche Analysen kann ''audit''-Modus sinnvoll sein, erhöht aber Log-Volumen deutlich
Zeile 192:
Zeile 192:
* Normalerweise ist in AppArmor-Profilen das Schreiben in das Stammverzeichnis / verboten:
* Normalerweise ist in AppArmor-Profilen das Schreiben in das Stammverzeichnis / verboten:
:* ''deny /foo w,''
:* ''deny /foo w,''
== Profile bearbeiten ==
Grundsätzlich können Profile in '''/etc/apparmor.d/''' manuell editiert werden.
* Es handelt sich um Textdateien mit eigener Regel-Syntax
* Ergänzende lokale Anpassungen werden in Dateien unter '''/etc/apparmor.d/local/''' vorgenommen, die per ''#include'' in das Hauptprofil eingebunden sind
; Hinweis
; Hinweis
* Netzwerkschnittstelle (''enp8s0'') ggf. an die lokale Bezeichnung anpassen (z.B. mittels ''ip addr'')
* Manuelles Editieren sollte die Ausnahme sein.
* Typische Änderungen (neue Pfade, zusätzliche Rechte) werden durch ''aa-logprof'' vorgenommen
* Bei Profilen, die über Paketverwaltung geliefert werden, gehen direkte Änderungen in '''/etc/apparmor.d/''' bei Updates verloren - lokale Anpassungen gehören nach '''/etc/apparmor.d/local/'''
== Weitere Profile beziehen ==
* Debian-basierte Systeme liefern bereits Profile für viele Standardprogramme
* Zusätzliche Regeln können über Pakete (''apparmor-profiles'', ''apparmor-profiles-extra'') installiert werden
* Fremde Profile sollten nur nach Prüfung der Quelle und anschließender Anpassung an die eigenen Anforderungen übernommen werden
=== Profile bearbeiten ===
== Konfiguration ==
Grundsätzlich ist es möglich, von Hand bestehende Profile zu bearbeiten oder neue zu erstellen
=== Verzeichnisstruktur ===
* Es handelt es sich um normale Textdateien
* Globale Einstellungen: '''/etc/apparmor'''
* Profile: '''/etc/apparmor.d/'''
* Deaktivierte Profile: symbolische Links in '''/etc/apparmor.d/disable'''
* Profile, die zwangsweise im ''complain''-Modus geladen werden: Links in '''/etc/apparmor.d/force-complain'''
; Achtung
=== ''disable'' und ''force-complain'' ===
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!
Enthält '''/etc/apparmor.d/disable''' eine Verknüpfung zu einem Profil, wird dieses nicht automatisch geladen.
* Verknüpfungen unter '''/etc/apparmor.d/force-complain''' sorgen dafür, dass Profile im ''complain''-Modus geladen werden.
==== Profilaufbau ====
Eine Profil-Datei ist dabei prinzipiell wie folgt aufgebaut
vergrößern
{| class="wikitable sortable options"
|-
|| 1
2
3
4
5
6
7
8
9
10
11
12
13
|| <nowiki>#include <tunables/global></nowiki>
/pfad/zur/anwendung {
<nowiki>#include <abstractions/base></nowiki>
[...]
capability sys_admin
[...]
<nowiki># Kommentar</nowiki>
/usr/lib/gconv/** r
/proc/meminfo r
/bin/basename rmix
[...]
}
|-
|}
* Mit dem Befehl <tt><nowiki>#include</nowiki></tt> können andere (grundlegende) Regelsätze eingebunden werden
* In allen Profilen ist grundsätzlich die Datei '''/etc/apparmor.d/tunables/global''' mit <tt><nowiki>#include</nowiki></tt> eingebunden, die wiederum weitere Dateien aus diesem Verzeichnis enthält, in denen u.a. Variablen wie <tt>@{HOME}</tt> (für alle [https://wiki.ubuntuusers.de/Homeverzeichnis/ Homeverzeichnisse]) oder <tt>@{PROC}</tt> (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, <tt><nowiki>#include</nowiki></tt>-Anweisungen, mit denen sogenannten <tt>abstractions</tt> eingebunden werden, und Kind-Profile (näheres dazu weiter unten)
* Mit dem Befehl <tt>capability XYZ</tt> werden grundlegende Eigenschaften/Merkmale definiert
* Siehe dazu die entsprechende [https://manpages.ubuntu.com/manpages/jammy/en/man7/capabilities.7.html Manpage] sowie [https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#Capability%20rules Capability rules]
* <tt>/PFAD/ZU/DATEI OPTION</tt> setzt die Berechtigungen für das jeweilige Verzeichnis bzw. die jeweilige Hilfsanwendung
* Dabei ist die Verwendung des Jokers <tt><nowiki>*</nowiki></tt> erlaubt, zwei <tt><nowiki>**</nowiki></tt> bedeuten "inkl. aller Unterverzeichnisse" (extended globbing)
* Beispiele dazu
{| class="wikitable sortable options"
|-
|| <tt>/ordner/datei</tt>
|| gilt für diese spezifische Datei '''datei''' in Verzeichnis '''/ordner'''
|-
|| <tt>/ordner/*</tt>
|| gilt für alle ''Dateien'' im Verzeichnis '''/ordner'''
|-
|| <tt>/ordner/a*</tt>
|| gilt für alle Dateien im Verzeichnis, die mit "a" beginnen
|-
|| <tt>/ordner/*.png</tt>
|| gilt für alle Dateien mit der Endung '''.png'''
|-
|| <tt>/ordner/[^.]*</tt>
|| gilt für alle Dateien in '''/ordner''' mit Ausnahme derjenigen, die mit einem "." beginnen
|-
|| <tt>/ordner/</tt>
|| gilt für das spezifische Verzeichnis '''/ordner'''
|-
|| <tt>/ordner/*/</tt>
|| gilt für jedes ''Verzeichnis'' in '''/ordner'''
|-
|| <tt>/ordner/**</tt>
|| gilt für jede ''Datei'' oder jedes ''Verzeichnis'' in oder unterhalb von '''/ordner'''
|-
|| <tt>/ordner/**/</tt>
|| gilt für jedes ''Verzeichnis'' in oder unterhalb von '''/ordner'''
|-
|}
Weitere Hinweise und Details finden sich unter [https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage#File_Globbing 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
{| class="wikitable sortable options"
|-
|| Attribut
|| Beschreibung
|-
|| <tt>audit</tt>
|| alle Anwendungen der Regel werden grundsätzlich geloggt
|-
|| <tt>owner</tt>
|| Berechtigung wird nur erteilt, wenn die Datei bzw. das Verzeichnis im Besitz des Benutzers ist
|-
|| <tt>deny</tt>
|| der Zugriff auf die Datei bzw. das Verzeichnis wird explizit verboten
|-
|}
<tt>deny</tt> 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
{| class="wikitable sortable options"
|-
|| 1
|| audit deny @{HOME}/.config/autostart/** wl
|-
|}
===== Netzwerkberechtigungen =====
== Problembehebung ==
AppArmor kann einer Anwendung den Netzwerkzugriff allgemein oder auch sehr spezifisch erlauben oder verbieten
Typische Schritte bei Problemen mit AppArmor-Profilen:
* Typische Beispiele
{| class="wikitable sortable options"
* Prüfen, ob der betroffene Prozess durch ein Profil eingeschränkt wird (''aa-status'')
|-
* Log-Meldungen zu diesem Prozess filtern (''grep apparmor'' auf ''syslog'' / ''kern.log'')
|| 1
* Profil mit ''aa-logprof'' anpassen
2
* Ggf. Profil temporär in ''complain''-Modus versetzen, um Verhalten zu analysieren
3
* Wenn nötig, Profil für die Fehlersuche kurzzeitig deaktivieren – danach wieder aktivieren
4
5
6
|| network, <nowiki># Netzwerkzugriff wird generell erlaubt</nowiki>
deny network, <nowiki># Netzwerkzugriff wird generell verboten </nowiki>
network tcp, <nowiki># TCP-Verbindungen werden erlaubt</nowiki>
network udp, <nowiki># UDP-Verbindungen werden erlaubt</nowiki>
network inet stream, <nowiki># IPv4 TCP-Verbindungen werden erlaubt</nowiki>
network inet6 dgram, <nowiki># IPv6 UDP-Verbindungen werden erlaubt</nowiki>
|-
|}
Weitere Details unter [https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#Network_rules Network rules]
===== Dateizugriffsberechtigungen =====
----
In AppArmor gibt es folgende Berechtigungen
{| class="wikitable sortable options"
|-
| colspan="2" | Dateizugriffsberechtigungen in AppArmor-Profilen
|-
|| Option
|| Beschreibung
|-
|| <tt>r</tt>
|| Lesezugriff ist erlaubt
|-
|| <tt>w</tt>
|| Schreibzugriff ist erlaubt
|-
|| <tt>a</tt>
|| Dateiinhalte können hinzugefügt werden
|-
|| <tt>l</tt>
|| Es ist erlaubt, einen Link zu erstellen
|-
|| <tt>k</tt>
|| Datei kann gesperrt werden (lockfile)
|-
|| <tt>m</tt>
|| Es darf der Aufruf von [https://manpages.ubuntu.com/manpages/jammy/en/man2/mmap.2.html mmap] erfolgen
|-
|| <tt>x</tt>
|| Hilfsanwendung darf ausgeführt werden
|-
|}
Die Option <tt>x</tt> kann nur in den folgenden Kombinationen verwendet werden
{| class="wikitable sortable options"
|-
| colspan="3" | Ausführungsberechtigungen in AppArmor-Profilen
|-
|| Option
|| englisch für
|| Beschreibung
|-
|| <tt>ux</tt>
|| unconfined execute mode
|| Hilfsanwendung ohne AppArmor-Überwachung ausführen
|-
|| <tt>Ux</tt>
|| unconfined execute - scrub the environment
|| wie <tt>ux</tt> mit Bereinigen der Umgebung
|-
|| <tt>ix</tt>
|| inherit execute mode
|| Hilfsanwendung erbt die Berechtigungen der Hauptanwendung
|-
|| <tt>px</tt>
|| discrete Profile execute mode
|| setzt die Definition eines eigenen Profils für die Hilfsanwendung voraus
|-
|| <tt>Px</tt>
|| Discrete Profile execute mode - scrub the environment
|| wie <tt>px</tt> mit Bereinigen der Umgebung
|-
|| <tt>cx</tt>
|| Execute and transition to a child profile
|| Ausführen der Hilfsanwendung über ein Kind-Profil innerhalb des Profils der Hauptanwendung
|-
|| <tt>Cx</tt>
|| Execute and transition to a child profile - scrub the environment
|| wie <tt>cx</tt> mit Bereinigen der Umgebung
|-
|}
Für die Ausführungsberechtigungen sind folgende Hinweise zu beachten:* Die Benutzung von <tt>ux</tt> wird nicht empfohlen, sofern nicht unbedingt notwendig
* Eine mit <tt>ux</tt> 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 <tt>Ux</tt> wird nicht empfohlen
* Zwar wird hier ein sog. [https://stackoverflow.com/questions/5835664/how-does-apparmor-do-environment-scrubbing "environment scrubbing"] durchgeführt (d. h. ein Bereinigen der Umgebung, indem [https://wiki.ubuntuusers.de/Umgebungsvariable/ Umgebungsvariable] wie <tt>LD_PRELOAD</tt> entfernt werden)
* Ansonsten gilt jedoch dieselbe Problematik wie unter <tt>ux</tt>
* Erheblich sicherer ist die Verwendung von <tt>ix</tt>
* 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 <tt>px</tt> (bzw. <tt>Px</tt>)
* 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 <tt>cx</tt> (bzw. <tt>Cx</tt>)
* Hier wird für die Hilfsanwendung ein lokales Profil innerhalb des Profils der Hauptanwendung angelegt
* Der Vorteil gegenüber <tt>px</tt> 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 [https://wiki.ubuntuusers.de/xdg-open/ 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: <br/>vergrößern
{| class="wikitable sortable options"
|-
|| 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
|| <nowiki># Last Modified: Sat Feb 16 18:28:03 2013</nowiki>
<nowiki>#include <tunables/global></nowiki>
/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 {
<nowiki>#include <abstractions/base></nowiki>
/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 <tt>cx</tt> und <tt>Cx</tt> 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
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 "<tt><nowiki>#include</nowiki></tt>" - 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 <tt><nowiki>#include</nowiki></tt> 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 "<tt><nowiki>#include <abstractions/private-files></nowiki></tt>" (oder u. U. in einer erweiterten Form mit "<tt><nowiki>#include <abstractions/private-files-strict></nowiki></tt>") 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 <tt>aa-logprof</tt>
* Eine manuelle Nachbearbeitung beschränkt sich daher im wesentlichen auf drei Fälle:
# Es sollte überprüft werden, ob man nicht mit <tt>aa-logprof</tt> versehentlich die gefährlichen Ausführungsmodi <tt>ux</tt> und <tt>Ux</tt> gewählt hat
# 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 <tt><nowiki>#</nowiki></tt>) zu erläutern
# 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 "<tt>deny</tt>"-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 "<tt><nowiki>#include</nowiki></tt>" in das zugehörige Profil eingebunden sind
* Alle hier manuell hinzugefügten Berechtigungen oder "<tt>deny</tt>"-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 [https://wiki.ubuntuusers.de/AppArmor/#disable-und-force-complain deaktiviert] sein könnten
* Um nun weitere Profile zu beziehen kann man
* Pakete mit weiteren Regeln installieren (siehe [https://wiki.ubuntuusers.de/AppArmor/#weitere-Regelsaetze 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
=== Problembehebung ===
== 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 [https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout 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 <tt>complain</tt>-Modus geladen werden ([https://wiki.ubuntuusers.de/AppArmor/#AppArmor-Modi-flags siehe unten])
=== Dateien ===
<noinclude>
<noinclude>
Version vom 11. Dezember 2025, 15:28 Uhr
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.
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:
sudoaa-complainPROFIL# Profil in den "complain"-Modus
sudoaa-enforcePROFIL# Profil in den "enforce"-Modus
sudoaa-auditPROFIL# Profil in den "audit"-Modus
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
sudoaa-enabled
Ausgabe:
Yes – AppArmor ist aktiv
No – AppArmor ist deaktiviert bzw. das Kernel-Modul nicht geladen
1. Basisprofil erzeugen
sudoaa-genprof/usr/sbin/PROGRAMM
Der Dienst wird gestartet/benutzt
aa-genprof wertet Log-Einträge aus und fragt interaktiv nach Freigaben/Verboten
2. Profil testen
Profil zunächst im complain-Modus belassen
Dienst normal verwenden und Logs auswerten
Bei Bedarf aa-logprof wiederholt ausführen, bis keine relevanten Verstöße mehr auftreten
3. Profil scharf schalten
sudoaa-enforce/usr/sbin/PROGRAMM
Der Dienst wird nun strikt gemäß Profil ausgeführt
Weitere Verstöße erscheinen als abgewiesene Zugriffe in den Logs
Logs auswerten
AppArmor schreibt Meldungen je nach Systemkonfiguration z.B. in:
/var/log/syslog
/var/log/kern.log
/var/log/audit/audit.log
Ein praktischer Live-Blick auf aktuelle Meldungen ist z.B.:
sudotail-F/var/log/syslog|grep"apparmor"
aa-logprof verarbeitet typischerweise Meldungen aus /var/log/syslog
Für umfangreiche Analysen kann audit-Modus sinnvoll sein, erhöht aber Log-Volumen deutlich
Die Protokollierungseinstellungen werden über die Datei /etc/apparmor/logprof.conf verwaltet
Deaktivieren und Reaktivieren
Die Steuerung von AppArmor erfolgt über einen Systemdienst.
Dienst und Profile entladen
sudoaa-teardown
Alle aktiven Profile werden aus dem Kernel entfernt
Danach finden keine AppArmor-Prüfungen mehr statt
Profile neu laden
sudosystemctlreloadapparmor.service
Lädt alle aktiven Profile aus /etc/apparmor.d/ neu
AppArmor Notify
Nach Installation von apparmor-notify können Desktop-Benachrichtigungen für verweigerte Zugriffe aktiviert werden
Aktivierung:
aa-notify-p
Test mit einem bewusst restriktiven Zugriff, z.B.:
sudotcpdump-ienp8s0-n-s0-w/foo
Der Befehl startet tcpdump und versucht Folgendes:
Lesen des Datenverkehrs von der Schnittstelle enp8s0
Speichern der erfassten Daten in einer Datei unter dem Pfad /foo (im Stammverzeichnis des Dateisystems)
Normalerweise ist in AppArmor-Profilen das Schreiben in das Stammverzeichnis / verboten:
deny /foo w,
Profile bearbeiten
Grundsätzlich können Profile in /etc/apparmor.d/ manuell editiert werden.
Es handelt sich um Textdateien mit eigener Regel-Syntax
Ergänzende lokale Anpassungen werden in Dateien unter /etc/apparmor.d/local/ vorgenommen, die per #include in das Hauptprofil eingebunden sind
Hinweis
Manuelles Editieren sollte die Ausnahme sein.
Typische Änderungen (neue Pfade, zusätzliche Rechte) werden durch aa-logprof vorgenommen
Bei Profilen, die über Paketverwaltung geliefert werden, gehen direkte Änderungen in /etc/apparmor.d/ bei Updates verloren - lokale Anpassungen gehören nach /etc/apparmor.d/local/
Weitere Profile beziehen
Debian-basierte Systeme liefern bereits Profile für viele Standardprogramme
Zusätzliche Regeln können über Pakete (apparmor-profiles, apparmor-profiles-extra) installiert werden
Fremde Profile sollten nur nach Prüfung der Quelle und anschließender Anpassung an die eigenen Anforderungen übernommen werden
Konfiguration
Verzeichnisstruktur
Globale Einstellungen: /etc/apparmor
Profile: /etc/apparmor.d/
Deaktivierte Profile: symbolische Links in /etc/apparmor.d/disable
Profile, die zwangsweise im complain-Modus geladen werden: Links in /etc/apparmor.d/force-complain
disable und force-complain
Enthält /etc/apparmor.d/disable eine Verknüpfung zu einem Profil, wird dieses nicht automatisch geladen.
Verknüpfungen unter /etc/apparmor.d/force-complain sorgen dafür, dass Profile im complain-Modus geladen werden.
Problembehebung
Typische Schritte bei Problemen mit AppArmor-Profilen:
Prüfen, ob der betroffene Prozess durch ein Profil eingeschränkt wird (aa-status)
Log-Meldungen zu diesem Prozess filtern (grep apparmor auf syslog / kern.log)
Profil mit aa-logprof anpassen
Ggf. Profil temporär in complain-Modus versetzen, um Verhalten zu analysieren
Wenn nötig, Profil für die Fehlersuche kurzzeitig deaktivieren – danach wieder aktivieren
