Zum Inhalt springen

AppArmor/Policy: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
VisuellWikitext
DanielZorin (Diskussion | Beiträge)
Bürokraten, Page Ownership admin
630 Bearbeitungen
Die Seite wurde neu angelegt: „==== 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>…“
 
DanielZorin (Diskussion | Beiträge)
Bürokraten, Page Ownership admin
630 Bearbeitungen
Keine Bearbeitungszusammenfassung
 
Zeile 1: Zeile 1:
==== Profilaufbau ====
== Profilaufbau ==
Eine Profil-Datei ist dabei prinzipiell wie folgt aufgebaut
Ein AppArmor-Profil definiert, welche Ressourcen eine konkrete ausführbare Datei verwenden darf. Grundstruktur:


vergrößern
<syntaxhighlight lang="ini" highlight="" line copy>
 
#include <tunables/global>
{| 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 {
/pfad/zur/anwendung {
<nowiki>#include <abstractions/base></nowiki>
  #include <abstractions/base>
[...]
  [...]
capability sys_admin
  capability sys_admin,
[...]
  [...]
<nowiki># Kommentar</nowiki>
  # Kommentar
/usr/lib/gconv/** r
  /usr/lib/gconv/** r,
/proc/meminfo r
  /proc/meminfo r,
/bin/basename rmix
  /bin/basename rmix,
[...]
  [...]
}
}
</syntaxhighlight>
* ''#include <tunables/global>'' bindet globale Variablen wie ''@{HOME}'' oder ''@{PROC}'' ein
* Der Pfad ''/pfad/zur/anwendung'' legt fest, für welche ausführbare Datei das Profil gilt
* Alle Regeln stehen innerhalb der geschweiften Klammern nach dem Profilnamen
* Jede Regelzeile endet mit einem Komma, mit Ausnahme von Kommentaren und ''#include''-Anweisungen.
* ''capability XYZ,'' definiert notwendige Kernel-Capabilities für den Prozess
* Dateiregeln der Form ''/PFAD/ZU/DATEI OPTIONEN,'' legen Zugriffsrechte für Dateien oder Verzeichnisse fest
* Jokerzeichen '''*''' und '''**''' ermöglichen Globbing über Dateien und Verzeichnisse
Typische Beispiele für Dateiglob-Pattern:
{| class="wikitable options big"
! Muster
! Beschreibung
|-
|-
| /ordner/datei
| gilt für die spezifische Datei ''datei'' im Verzeichnis ''/ordner''
|-
| /ordner/*
| gilt für alle Dateien im Verzeichnis ''/ordner''
|-
| /ordner/a*
| gilt für alle Dateien im Verzeichnis, deren Name mit ''a'' beginnt
|-
| /ordner/*.png
| gilt für alle Dateien mit der Endung ''.png''
|-
| /ordner/[^.]*
| gilt für alle Dateien in ''/ordner'' mit Ausnahme derjenigen, die mit ''.'' beginnen
|-
| /ordner/
| gilt für das Verzeichnis ''/ordner''
|-
| /ordner/*/
| gilt für jedes Unterverzeichnis 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''
|}
|}
* 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.&nbsp;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.&nbsp;die jeweilige Hilfsanwendung
* Dabei ist die Verwendung des Jokers <tt><nowiki>*</nowiki></tt> erlaubt, zwei <tt><nowiki>**</nowiki></tt> bedeuten "inkl.&nbsp;aller Unterverzeichnisse" (extended globbing)
* Beispiele dazu


{| class="wikitable sortable options"
== Berechtigungen ==
|-  
Grundprinzip: Ein Prozess mit AppArmor-Profil darf nur, was im Profil explizit erlaubt ist
|| <tt>/ordner/datei</tt>
* Fehlt z.B. jede Regel für das Home-Verzeichnis, werden Zugriffe auf dieses Verzeichnis blockiert
|| gilt für diese spezifische Datei '''datei''' in Verzeichnis '''/ordner'''
 
|-
=== Dateirechte ===
|| <tt>/ordner/*</tt>
Dateizugriffe werden über Einzelbuchstaben kombiniert:
|| gilt für alle ''Dateien'' im Verzeichnis '''/ordner'''
 
|-  
{| class="wikitable sortable options big"
|| <tt>/ordner/a*</tt>
|-
|| gilt für alle Dateien im Verzeichnis, die mit "a" beginnen
! Option
|-
! Beschreibung
|| <tt>/ordner/*.png</tt>
|-
|| gilt für alle Dateien mit der Endung '''.png'''
| r
|-
| Lesezugriff auf Datei oder Verzeichnis
|| <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'''
|-
|-
| w
| Schreibzugriff (Ändern, Anlegen, Löschen)
|-
| a
| Anhängen an bestehende Datei (Append)
|-
| l
| Erstellen und Auflösen von Links
|-
| k
| Sperren einer Datei (Lockfile)
|-
| m
| Nutzung von Speicherabbildungen (mmap)
|-
| x
| Ausführen einer Hilfsanwendung
|}
|}
Weitere Hinweise und Details finden sich unter [https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage#File_Globbing File Globbing]


==== Berechtigungen ====
Beispiel:
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 =====
<syntaxhighlight lang="ini" line copy>
Darüber hinaus gibt es drei zusätzliche Attribute
/var/log/meinprogramm/** rw,
@{HOME}/.meinprogramm/** r,
</syntaxhighlight>


{| class="wikitable sortable options"  
=== Attribute ===
|-
Zusätzlich zu den Zugriffsrechten können Attribute gesetzt werden:
|| Attribut
 
|| Beschreibung
{| class="wikitable sortable options big"
|-  
! Attribut
|| <tt>audit</tt>
! Beschreibung
|| alle Anwendungen der Regel werden grundsätzlich geloggt
|-
|-  
| audit
|| <tt>owner</tt>
| alle Anwendungen der Regel werden protokolliert
|| Berechtigung wird nur erteilt, wenn die Datei bzw.&nbsp;das Verzeichnis im Besitz des Benutzers ist
|-
|-
| owner
|| <tt>deny</tt>
| die Regel gilt nur, wenn der aufrufende Benutzer Besitzer der Datei/des Verzeichnisses ist
|| der Zugriff auf die Datei bzw.&nbsp;das Verzeichnis wird explizit verboten
|-
|-
| deny
| Zugriff auf Datei/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


|-
Beispiel:
|}


===== Netzwerkberechtigungen =====
<syntaxhighlight lang="ini" highlight="" line copy>
AppArmor kann einer Anwendung den Netzwerkzugriff allgemein oder auch sehr spezifisch erlauben oder verbieten
audit deny @{HOME}/.config/autostart/** wl,
* Typische Beispiele
</syntaxhighlight>


{| class="wikitable sortable options"
* Diese Regel verbietet explizit Zugriffe auf Autostart-Dateien, protokolliert aber gleichzeitig jede solche Zugriffsanfrage.
|-  
|| 1
2
3
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 =====
=== Netzwerkrechte ===
In AppArmor gibt es folgende Berechtigungen
Netzwerkzugriffe werden über eigene Regeln gesteuert:


{| class="wikitable sortable options"  
{| class="wikitable sortable options big"
|-
! Regel
| colspan="2" | Dateizugriffsberechtigungen in AppArmor-Profilen
! Beschreibung
|-
|-
|| Option
| network,
|| Beschreibung
| allgemeiner Netzwerkzugriff wird erlaubt
|-  
|| <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
|-
|-
|}
| deny network,
Die Option <tt>x</tt> kann nur in den folgenden Kombinationen verwendet werden
| jeglicher Netzwerkzugriff wird verboten
 
|-
{| class="wikitable sortable options"
| network tcp,
|-  
| TCP-Verbindungen werden erlaubt
| colspan="3" | Ausführungsberechtigungen in AppArmor-Profilen
|-
|-  
| network udp,
|| Option
| UDP-Verbindungen werden erlaubt
|| englisch für
|-
|| Beschreibung
| network inet stream,
|-  
| IPv4-TCP-Verbindungen werden erlaubt
|| <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
|-
|-
| network inet6 dgram,
| IPv6-UDP-Verbindungen werden erlaubt
|}
|}
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.&nbsp;U.&nbsp;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.&nbsp;h.&nbsp;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.&nbsp;a.&nbsp;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"
Beispiel:
|-
|| 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 {
<syntaxhighlight lang="ini" line copy>
[...]
network inet stream,
/opt/google/chrome/xdg-settings Cx
deny network inet6 dgram,
[...]
</syntaxhighlight>
/usr/bin/xdg-open Cx
/usr/bin/xdg-settings Cx


[...]
* IPv4-TCP ist erlaubt, IPv6-UDP wird explizit verboten.


profile /opt/google/chrome/xdg-settings {
=== Ausführungsmodi ===
Die Ausführung von Hilfsanwendungen wird über Kombinationen mit ''x'' gesteuert:


/bin/dash r
{| class="wikitable sortable options big"
/bin/grep rix
|-
/bin/readlink rix
! Option
[...]
! englische Bezeichnung
}
! Beschreibung
|-
| ux
| unconfined execute mode
| Hilfsanwendung ohne AppArmor-Einschränkung ausführen
|-
| Ux
| unconfined execute – scrub the environment
| wie ''ux'', aber mit Bereinigung ausgewählter Umgebungsvariablen
|-
| ix
| inherit execute mode
| Hilfsanwendung erbt das Profil der aufrufenden Anwendung
|-
| px
| discrete profile execute mode
| es muss ein separates Profil für die Hilfsanwendung existieren
|-
| Px
| discrete profile execute – scrub the environment
| wie ''px'' mit zusätzlicher Bereinigung der Umgebung
|-
| cx
| execute and transition to a child profile
| Wechsel in ein Kind-Profil innerhalb des aktuellen Profils
|-
| Cx
| execute and transition to a child profile – scrub the environment
| wie ''cx'' mit Bereinigung der Umgebung
|}


profile /usr/bin/xdg-open {
* ''ux'' und ''Ux'' nur im Ausnahmefall verwenden, da die Hilfsanwendung ohne zusätzliche Einschränkungen läuft
<nowiki>#include <abstractions/base></nowiki>
* ''ix'' ist sinnvoll, wenn Hilfsanwendung exakt dieselben Rechte wie die Hauptanwendung haben soll
* ''px''und''Px'' trennen Rechte der Hilfsanwendung über ein eigenes Profil sauber von der Hauptanwendung
* ''cx''und''Cx'' eignen sich für Kind-Profile, bei denen die Hilfsanwendung je nach Aufrufer unterschiedliche Rechte erhält


/bin/dash r
Beispiel für eine Kind-Profil-Definition:
/etc/X11/cursors/oxy-white.theme r
[...]
}


profile /usr/bin/xdg-settings {
<syntaxhighlight lang="ini" highlight="" line copy>
/usr/bin/hauptprogramm {
  [...]
  /usr/bin/hilfsprogramm Cx -> hilfsprogramm_child,
  [...]


/bin/cat rix
  profile hilfsprogramm_child {
/bin/dash r
    /etc/hilfsprogramm.conf r,
[...]
    /var/lib/hilfsprogramm/** rw,
}
    [...]
  }
}
}
|-
</syntaxhighlight>
|}
 
* Als weitere Variante mit <tt>cx</tt> und <tt>Cx</tt> ist eine sog. "named profile transition" möglich
== Abstractions ==
* Hier wird ein Kind-Profil namentlich explizit definiert
Im Verzeichnis ''/etc/apparmor.d/abstractions'' befinden sich vorgefertigte Regelsätze ('''abstractions''').
* 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
* Sie bündeln häufig genutzte Rechte (z.B. Desktop, X11, Netzwerk, lokale Konfiguration)
* Die Syntax ändert sich dann in:<br/>vergrößern
* Über ''#include <abstractions/name>'' können diese Regelsätze in Profile eingebunden werden
* Dadurch reduziert sich der Umfang einzelner Profile und gemeinsame Regeln werden zentral gepflegt
 
; Hinweis
* Viele ''abstractions'' binden wiederum andere ''abstractions'' ein, die effektiven Berechtigungen sind dadurch nicht immer sofort ersichtlich
* Die Verwendung mehrerer ''abstractions'' kann dazu führen, dass einer Anwendung mehr Rechte als nötig eingeräumt werden.
* Konfliktierende Regeln aus unterschiedlichen ''abstractions'' können dazu führen, dass ein Profil nicht geladen werden kann
* Wenn Werkzeuge zur Profilerstellung wahlweise eine konkrete Regel oder eine ''abstraction'' vorschlagen, ist die konkrete Regel in der Regel restriktiver und besser kontrollierbar
* Zur Absicherung sensibler Bereiche können gezielt spezielle ''abstractions'' (z.B. für private Dateien) ergänzt werden
 
== Profilbearbeitung ==


{| class="wikitable sortable options"
Neue Regeln werden üblicherweise anhand von Log-Einträgen schrittweise ergänzt
|-  
* Komplexe Profile können über Kommentare und Gruppierung der Regeln besser strukturiert werden
|| 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|| <nowiki>#include <tunables/global></nowiki>


/opt/google/chrome/chrome {
Anlässe für manuelle Anpassungen:
[...]
/opt/google/chrome/xdg-settings Cx -> gemeinsame_xdg_settings
[...]
/usr/bin/xdg-settings Cx -> gemeinsame_xdg_settings


[...]
# Kontrolle, ob für Hilfsanwendungen versehentlich ''ux''/''Ux'' verwendet wurde
# Umstrukturierung des Profils zur besseren Lesbarkeit (Gruppierung nach Pfaden oder Funktion)
# Nachträgliche Einschränkung zu weit gefasster Regeln, z.B. durch zusätzliche ''deny''-Regeln für besonders kritische Dateien oder Verzeichnisse


profile gemeinsame_xdg_settings {


/bin/dash r
Profile, die durch Paketverwaltung bereitgestellt werden, sollten nicht direkt überschrieben werden
/bin/grep rix
* Zusätzliche lokale Regeln gehören in die zugehörigen Dateien unter ''/etc/apparmor.d/local'', die in das Hauptprofil eingebunden werden
/bin/readlink rix
* Auf diese Weise bleiben lokale Anpassungen auch bei Updates des Hauptprofils erhalten
[...]
}
}
|-
|}
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. &nbsp;Folgende Hinweise sollten dabei beachtet werden:
<noinclude>
* 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 "...&nbsp;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.&nbsp;U.&nbsp;in einer erweiterten Form mit "<tt><nowiki>#include <abstractions/private-files-strict></nowiki></tt>") zu ergänzen


==== Generelle Hinweise zur Profilbearbeitung ====
== Anhang ==
Das manuelle Editieren eines AppArmor-Profils sollte die Ausnahme darstellen
=== Siehe auch ===
* In der Praxis erfolgt das Hinzufügen von Regeln zu einem Profil mit Hilfe von <tt>aa-logprof</tt>
<div style="column-count:2">
* Eine manuelle Nachbearbeitung beschränkt sich daher im wesentlichen auf drei Fälle:
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
# 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
</div>
# Es macht bei umfangreichen Profilen u.U.&nbsp;Sinn, zum Zwecke einer besseren Übersichtlichkeit die Regeln zu gruppieren bzw.&nbsp;anders zu sortieren oder auch ggfs.&nbsp;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
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}


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
=== Dokumentation ===
* 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
; Man-Page
* 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
; Info-Pages
-->


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
=== Links ===
* Außerdem sind diese Regeln meist nicht auf die eigenen Bedürfnisse angepasst, sondern müssen nachträglich feinjustiert werden
==== Projekt ====
* Auch hier gilt, dass keine Profile blind übernommen werden sollten
==== Weblinks ====


=== Problembehebung ===
<!--
== Konfiguration ==
{{DEFAULTSORT:new}}
=== Verzeichnisstruktur ===
{{DISPLAYTITLE:new}}
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])
[[Kategorie:AppArmor]]
[[Kategorie:AppArmor]]
</noinclude>

Aktuelle Version vom 12. Dezember 2025, 16:12 Uhr

Profilaufbau

Ein AppArmor-Profil definiert, welche Ressourcen eine konkrete ausführbare Datei verwenden darf. Grundstruktur: 

#include <tunables/global>

/pfad/zur/anwendung {
  #include <abstractions/base>
  [...]
  capability sys_admin,
  [...]
  # Kommentar
  /usr/lib/gconv/** r,
  /proc/meminfo r,
  /bin/basename rmix,
  [...]
}
  • #include <tunables/global> bindet globale Variablen wie @{HOME} oder @{PROC} ein
  • Der Pfad /pfad/zur/anwendung legt fest, für welche ausführbare Datei das Profil gilt
  • Alle Regeln stehen innerhalb der geschweiften Klammern nach dem Profilnamen
  • Jede Regelzeile endet mit einem Komma, mit Ausnahme von Kommentaren und #include-Anweisungen.
  • capability XYZ, definiert notwendige Kernel-Capabilities für den Prozess
  • Dateiregeln der Form /PFAD/ZU/DATEI OPTIONEN, legen Zugriffsrechte für Dateien oder Verzeichnisse fest
  • Jokerzeichen * und ** ermöglichen Globbing über Dateien und Verzeichnisse

Typische Beispiele für Dateiglob-Pattern:

Muster Beschreibung
/ordner/datei gilt für die spezifische Datei datei im Verzeichnis /ordner
/ordner/* gilt für alle Dateien im Verzeichnis /ordner
/ordner/a* gilt für alle Dateien im Verzeichnis, deren Name mit a beginnt
/ordner/*.png gilt für alle Dateien mit der Endung .png
/ordner/[^.]* gilt für alle Dateien in /ordner mit Ausnahme derjenigen, die mit . beginnen
/ordner/ gilt für das Verzeichnis /ordner
/ordner/*/ gilt für jedes Unterverzeichnis 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

Berechtigungen

Grundprinzip: Ein Prozess mit AppArmor-Profil darf nur, was im Profil explizit erlaubt ist

  • Fehlt z.B. jede Regel für das Home-Verzeichnis, werden Zugriffe auf dieses Verzeichnis blockiert

Dateirechte

Dateizugriffe werden über Einzelbuchstaben kombiniert:

Option Beschreibung
r Lesezugriff auf Datei oder Verzeichnis
w Schreibzugriff (Ändern, Anlegen, Löschen)
a Anhängen an bestehende Datei (Append)
l Erstellen und Auflösen von Links
k Sperren einer Datei (Lockfile)
m Nutzung von Speicherabbildungen (mmap)
x Ausführen einer Hilfsanwendung

Beispiel: 

/var/log/meinprogramm/** rw,
@{HOME}/.meinprogramm/** r,

Attribute

Zusätzlich zu den Zugriffsrechten können Attribute gesetzt werden:

Attribut Beschreibung
audit alle Anwendungen der Regel werden protokolliert
owner die Regel gilt nur, wenn der aufrufende Benutzer Besitzer der Datei/des Verzeichnisses ist
deny Zugriff auf Datei/Verzeichnis wird explizit verboten

Beispiel: 

audit deny @{HOME}/.config/autostart/** wl,
  • Diese Regel verbietet explizit Zugriffe auf Autostart-Dateien, protokolliert aber gleichzeitig jede solche Zugriffsanfrage.

Netzwerkrechte

Netzwerkzugriffe werden über eigene Regeln gesteuert:

Regel Beschreibung
network, allgemeiner Netzwerkzugriff wird erlaubt
deny network, jeglicher Netzwerkzugriff wird 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

Beispiel: 

network inet stream,
deny network inet6 dgram,
  • IPv4-TCP ist erlaubt, IPv6-UDP wird explizit verboten.

Ausführungsmodi

Die Ausführung von Hilfsanwendungen wird über Kombinationen mit x gesteuert:

Option englische Bezeichnung Beschreibung
ux unconfined execute mode Hilfsanwendung ohne AppArmor-Einschränkung ausführen
Ux unconfined execute – scrub the environment wie ux, aber mit Bereinigung ausgewählter Umgebungsvariablen
ix inherit execute mode Hilfsanwendung erbt das Profil der aufrufenden Anwendung
px discrete profile execute mode es muss ein separates Profil für die Hilfsanwendung existieren
Px discrete profile execute – scrub the environment wie px mit zusätzlicher Bereinigung der Umgebung
cx execute and transition to a child profile Wechsel in ein Kind-Profil innerhalb des aktuellen Profils
Cx execute and transition to a child profile – scrub the environment wie cx mit Bereinigung der Umgebung
  • ux und Ux nur im Ausnahmefall verwenden, da die Hilfsanwendung ohne zusätzliche Einschränkungen läuft
  • ix ist sinnvoll, wenn Hilfsanwendung exakt dieselben Rechte wie die Hauptanwendung haben soll
  • pxundPx trennen Rechte der Hilfsanwendung über ein eigenes Profil sauber von der Hauptanwendung
  • cxundCx eignen sich für Kind-Profile, bei denen die Hilfsanwendung je nach Aufrufer unterschiedliche Rechte erhält

Beispiel für eine Kind-Profil-Definition: 

/usr/bin/hauptprogramm {
  [...]
  /usr/bin/hilfsprogramm Cx -> hilfsprogramm_child,
  [...]

  profile hilfsprogramm_child {
    /etc/hilfsprogramm.conf r,
    /var/lib/hilfsprogramm/** rw,
    [...]
  }
}

Abstractions

Im Verzeichnis /etc/apparmor.d/abstractions befinden sich vorgefertigte Regelsätze (abstractions).

  • Sie bündeln häufig genutzte Rechte (z.B. Desktop, X11, Netzwerk, lokale Konfiguration)
  • Über #include <abstractions/name> können diese Regelsätze in Profile eingebunden werden
  • Dadurch reduziert sich der Umfang einzelner Profile und gemeinsame Regeln werden zentral gepflegt
Hinweis
  • Viele abstractions binden wiederum andere abstractions ein, die effektiven Berechtigungen sind dadurch nicht immer sofort ersichtlich
  • Die Verwendung mehrerer abstractions kann dazu führen, dass einer Anwendung mehr Rechte als nötig eingeräumt werden.
  • Konfliktierende Regeln aus unterschiedlichen abstractions können dazu führen, dass ein Profil nicht geladen werden kann
  • Wenn Werkzeuge zur Profilerstellung wahlweise eine konkrete Regel oder eine abstraction vorschlagen, ist die konkrete Regel in der Regel restriktiver und besser kontrollierbar
  • Zur Absicherung sensibler Bereiche können gezielt spezielle abstractions (z.B. für private Dateien) ergänzt werden

Profilbearbeitung

Neue Regeln werden üblicherweise anhand von Log-Einträgen schrittweise ergänzt

  • Komplexe Profile können über Kommentare und Gruppierung der Regeln besser strukturiert werden

Anlässe für manuelle Anpassungen:

  1. Kontrolle, ob für Hilfsanwendungen versehentlich ux/Ux verwendet wurde
  2. Umstrukturierung des Profils zur besseren Lesbarkeit (Gruppierung nach Pfaden oder Funktion)
  3. Nachträgliche Einschränkung zu weit gefasster Regeln, z.B. durch zusätzliche deny-Regeln für besonders kritische Dateien oder Verzeichnisse


Profile, die durch Paketverwaltung bereitgestellt werden, sollten nicht direkt überschrieben werden

  • Zusätzliche lokale Regeln gehören in die zugehörigen Dateien unter /etc/apparmor.d/local, die in das Hauptprofil eingebunden werden
  • Auf diese Weise bleiben lokale Anpassungen auch bei Updates des Hauptprofils erhalten



Anhang

Siehe auch


Dokumentation

Links

Projekt

Weblinks


Abgerufen von „https://wiki.foxtom.de/index.php?title=AppArmor/Policy&oldid=158847“