40.2AppArmor
Anstatt das komplexe SELinux-System für die eigenen Distributionen zu adaptieren, kaufte Novell 2005 die Firma Immunix, gab dessen Sicherheitslösung Subdomain den neuen Namen AppArmor, stellte sie unter die GPL und entwickelte einige YaST-Module zur Administration. Einige Jahre später erhielt AppArmor gewissermaßen den Ritterschlag der Kernelentwickler und wurde offiziell in den Kernel integriert. Danach ist bei SUSE rund um AppArmor aber Stille eingekehrt. AppArmor ist zwar weiter im Einsatz, in den letzten Jahren sind aber weder an den Regeln noch an den Administrationswerkzeugen merkbare Verbesserungen durchgeführt worden. Um die AppArmor-Weiterentwicklung kümmern sich seither vor allem von Canonical angestellte Entwickler.
AppArmor ist wie SELinux ein MAC-Sicherheitssystem (Mandatory Access Control). Im Unterschied zu SELinux basieren AppArmor-Regeln auf absoluten Dateinamen. Daher ist eine eigene Kennzeichnung aller Dateien durch EAs nicht erforderlich; zudem funktioniert AppArmor auch für Dateisysteme, die keine EAs unterstützen. In den AppArmor-Regeln sind Jokerzeichen erlaubt. Aus diesem Grund kommt AppArmor für typische Anwendungsfälle mit wesentlich weniger Regeln aus als SELinux.
Naturgemäß gibt es auch Argumente, die gegen AppArmor sprechen:
-
Sicherheitsexperten von Red Hat sind der Meinung, dass absolute Pfade in den Regeln ein inhärentes Sicherheitsrisiko sind. Der Schutz von AppArmor kann durch das Umbenennen von Dateien oder Verzeichnissen umgangen werden – was natürlich nur gelingt, wenn ein Angreifer dazu bereits ausreichende Rechte hat.
-
Das Regelwerk für AppArmor ist nicht so umfassend wie das von SELinux. Standardmäßig werden weniger Programme geschützt. Zwar ist es einfacher als bei SELinux, selbst Regeln zu erstellen bzw. zu ändern, aber diese Art der Do-it-yourself-Sicherheit hinterlässt einen wenig professionellen Eindruck.
Dieser Abschnitt gibt nur eine Einführung zu AppArmor. Weitere Informationen finden Sie hier:
https://www.suse.com/de-de/documentation/sles11
https://wiki.ubuntu.com/AppArmor
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles
AppArmor unter Ubuntu
Die folgenden Ausführungen beziehen sich auf AppArmor, wie es unter Ubuntu aktiv ist. SUSE-spezifische Anmerkungen folgen am Ende dieses Abschnitts.
AppArmor ist unter Ubuntu standardmäßig im Kernel integriert. Das Sicherheitssystem wird durch das Init-V-Script /etc/init.d/apparmor gestartet. Es berücksichtigt die Grundkonfiguration aus dem Verzeichnis /etc/apparmor und lädt alle Regeldateien aus dem Verzeichnis /etc/apparmor.d. Das Init-Script greift auf Funktionen zurück, die in /etc/apparmor/rc.apparmor.functions definiert sind.
Das Kommando aa-status gibt einen Überblick über den gegenwärtigen Zustand von AppArmor. Das Kommando liefert sowohl eine Liste aller Profile als auch eine Liste der tatsächlich überwachten Prozesse. Die folgende Liste zeigt an, welche Dienste eines Ubuntu-Root-Servers überwacht werden:
Beim Start von AppArmor wird das Dateisystem securityfs in das Verzeichnis /sys/kernel/security eingebunden. Seine Dateien geben Auskunft über aktive Profile, die Anzahl der aufgetretenen Regelverletzungen etc.
Die Wirkung von AppArmor steht und fällt mit den Überwachungsregeln. Diese Regeln werden auch »Profile« genannt und befinden sich in den Dateien des Verzeichnisses /etc/apparmor.d/. Beispielsweise enthält die Datei usr.sbin.cupsd die Profile für CUPS und den CUPS-PDF-Treiber.
Die offiziell gewarteten Regelprofile werden üblicherweise vom jeweiligen Paket zur Verfügung gestellt. Das Regelprofil user.sbin.cupsd steht also nur dann zur Verfügung, wenn Sie das Druckersystem CUPS installiert haben. Aus diesem Grund ist /etc/apparmor.d nach einer Ubuntu-Server-Installation anfänglich fast leer und füllt sich erst in dem Ausmaß, in dem Sie Server-Dienste installieren.
Außerdem können Sie das Paket apparmor-profiles aus der universe-Paketquelle installieren. Es enthält zahlreiche weitere Profile, die aber nicht offiziell unterstützt und gewartet werden. Die meisten Profile laufen nur im sogenannten complain-Modus: In diesem Modus werden Regelverstöße zwar protokolliert, aber nicht geahndet. Mit den Kommandos aa-enforce und aa-complain aus dem Paket apparmor-utils können Sie den Modus eines Profils ändern. An die beiden Kommandos übergeben Sie den vollständigen Pfad des zu überwachenden Programms:
Alternativ können Sie an aa-enforce und aa-complain auch die Dateinamen der Profildateien übergeben. Das macht es einfach, den Modus mehrerer Profile auf einmal zu verändern:
Bei Server-Diensten müssen Sie nach einer Aktivierung eines AppArmor-Profils auch das jeweilige Programm neu starten:
Losgelöst vom AppArmor-Modus sind Profile natürlich nur dann relevant, wenn das betreffende Programm tatsächlich ausgeführt wird. Welche Programme momentan aktiv überwacht werden, verrät das oben erwähnte Kommando aa-status.
Regeldateien, die bei AppArmor Profile heißen, liegen in einem einfachen Textformat vor. Die folgenden Zeilen zeigen die AppArmor-Regeln für mysqld:
In den Regeldateien werden zuerst einige Include-Dateien gelesen und dann grundlegende Merkmale (siehe man capabilities) des Programms festgelegt. Die weiteren Regeln geben an, welche Dateien das Programm wie nutzen darf.
In den AppArmor-Regeldateien gilt das Jokerzeichen * als Platzhalter für eine beliebige Anzahl von Zeichen. ** hat eine ähnliche Bedeutung, schließt aber das Zeichen / ein und umfasst damit auch Dateien in allen Unterverzeichnissen. Die Zugriffsrechte werden durch Buchstaben oder Buchstabenkombinationen ausgedrückt, deren Bedeutung im AppArmor-Administration-Manual genau beschrieben ist. Tabelle 40.1 beschreibt die wichtigsten Buchstaben. Die ?x-Kombinationen steuern die Rechte von Sub-Prozessen, die das Hauptprogramm startet.
|
Kürzel |
Bedeutung |
|---|---|
|
r |
erlaubt Lesezugriffe (read). |
|
w |
erlaubt Schreibzugriffe (write). |
|
a |
erlaubt es, die Datei zu erweitern (append). |
|
l |
wendet auf harte Links dieselben Regeln wie für die Ursprungsdatei an (link). |
|
k |
erlaubt es, die Datei zu blockieren (lock). |
|
m |
lässt die mmap-Funktion zu (allow executable mapping). |
|
ix |
Das Programm erbt die Regeln des Basisprogramms (inherent execute). |
|
px |
Das Programm hat ein eigenes AppArmor-Profil (discrete profile execute). |
|
ux |
führt das Programm ohne AppArmor-Regeln aus (unconstrained execute). |
Tabelle 40.1Elementare AppArmor-Zugriffsrechte
AppArmor sieht einen Mechanismus vor, um einzelne Parameter der Regeln auf eine einfache Weise zu verändern. Diese Parameter sind in den Dateien des Verzeichnisses /etc/apparmor.d/tunables definiert. In der aktuellen Implementierung gibt es allerdings nur wenige Parameter, mit denen Sie beispielsweise den Ort der Heimatverzeichnisse individuell einstellen können. Wenn Ihr Server außer /home auch andere Orte für Heimatverzeichnisse vorsieht, müssen Sie die Variable @{HOMEDIRS} verändern. Im folgenden Beispiel wurden dort die beiden zusätzlichen Verzeichnisse /home1 und /myhome hinzugefügt.
Details über Regelverletzungen, die im complain- oder enforce-Modus stattfanden, werden in Form von Kernelmeldungen weitergegeben und standardmäßig in den Dateien /var/log/kern.log und /var/log/syslog aufgezeichnet. Sie erkennen AppArmor-Meldungen am Schlüsselwort audit.
Oft sind die Audit-Meldungen ein Indikator dafür, dass die AppArmor-Regeln unvollständig sind. Ein Fehlverhalten des Programms ist natürlich auch möglich, aber eher unwahrscheinlich. Mit Sicherheit kann das nur ein Experte für das jeweilige Programm beurteilen. Insofern ist eine angemessene Reaktion auf Regelübertretungen schwierig.
Wenn Sie vermuten, dass das betroffene Programm ordnungsgemäß funktioniert, sollten Sie das Profil in den complain-Modus umschalten und die Audit-Meldung im Ubuntu-Bug-System melden (https://bugs.launchpad.net). Sie können auch versuchen, das Profil um eine Regel zu erweitern, die den gemeldeten Vorgang erlaubt. Oder Sie ignorieren die Meldung einfach, sofern das betroffene Programm anstandslos weiterläuft.
AppArmor unter SUSE
AppArmor ist in aktuellen openSUSE- und SUSE-Enterprise-Distributionen standardmäßig installiert und aktiv. YaST enthält sogar ein Modul zur AppArmor-Konfiguration (siehe Abbildung 40.2). Dessen Funktionalität reicht aber nicht weit über die der Kommandos aa-status, aa-enforce und aa-complain hinaus. Einige Dialogpunkte führen überhaupt zum Absturz des Moduls.
Abbildung 40.2YaST-Modul zur AppArmor-Konfiguration
AppArmor wird am Beginn des Init-Prozesses durch das Script /etc/init.d/boot.apparmor gestartet. Das Script ist also ein Relikt aus der Init-V-Vergangenheit von SUSE und ein Indikator dafür, dass die Liebe der SUSE-Entwickler zu AppArmor weitgehend erloschen ist. Dieses Script greift wiederum auf Funktionen zurück, die in /lib/apparmor/rc.apparmor.functions definiert sind. boot.apparmor liest die Grundkonfiguration aus dem Verzeichnis /etc/apparmor und lädt alle Regeldateien aus dem Verzeichnis /etc/apparmor.d.
Änderungen an der Konfiguration werden erst wirksam, wenn Sie AppArmor neu starten bzw. die Regeldateien neu einlesen: