Mit SELinux (Security-Enhanced Linux) existiert bereits seit einiger Zeit eine Linux-Erweiterung, die über das klassische Rechtemodell auf Dateisystembasis hinausgeht und Mandatory Access Controls implementiert. Allerdings hat SELinux den Ruf, nicht gerade einfach zu bedienen zu sein. Novell hat nun mit AppArmor eine deutlich leichter verdauliche Alternative geschaffen, die bereits seit Suse Linux 10 Bestandteil der eigenen Distributionen ist, aber auch weniger Möglichkeiten als SELinux bietet.
Mandatory Access Controls (MAC) stellen eine wichtige Erweiterung des klassischen Unix-Rechte-Konzepts dar. Denn sie ermöglichen eine feiner granulierte Zugriffssteuerung, die nicht einmal auf Dateien begrenzt sein muss, sondern auch auf Prozesse oder Ressourcen wie Netzwerkverbindungen erweitert werden kann. Dabei wird nicht anhand der Identität des Anwenders und des jeweiligen Objekts, auf das zugegriffen werden soll, über die Zugriffsberechtigung entschieden, sondern aufgrund von Regeln und Eigenschaften des Anwenders und des Objekts. Das Problem bei MAC besteht jedoch in der komplexen Konfiguration, da im Prinzip für jedes Programm oder jede Datei Regelsätze definiert werden müssen. Dies ist selbst bei Servern mit einem limitierten Funktionsumfang mit einem sehr grossen Aufwand verbunden. Dies verschärft sich im Falle von SELinux noch dadurch, dass es Label-basiert ist und über m4-Macros konfiguriert wird, was nicht sonderlich anwenderfreundlich ist. Die Komplexität ist es also, die dazu führt, dass das von der National Security Agency federführend entwickelte SELinux nicht wirklich verbreitet ist, obwohl es zur Standardausstattung des Linux-Kernels und der Distributionen aus dem Hause Red Hat gehört.
Einen etwas anderen Weg geht nun Novell mit AppArmor. AppArmor hiess ursprünglich Subdomain und war das Hauptprodukt von Immunix, bevor das Unternehmen samt der Produkte von Novell aufgekauft und Subdomain in AppArmor umgetauft wurde. Es hat mit SELinux auf den ersten Blick einiges gemeinsam: So gehört es zur Standardausstattung der Linux-Distributionen von Novell, klinkt sich ebenfalls über das Linux-Security-Modules-Interface (LSM) in den Kernel ein und implementiert MAC. AppArmor verzichtet aber durch eine andere Funktionsweise und deutlich weniger Features auf die Komplexität von SELinux. Zudem sind die Konfigurationsdateien viel einfacher zu verstehen. Vereinfacht gesagt ist SELinux für den Profi und AppArmor auf den ambitionierten Einsteiger zugeschnitten.
AppArmor verwendet statt Labels, die über Extended Attributes an Dateien und Programme gehängt werden, einen auf Pfaden und POSIX Capabilities basierenden Ansatz, um den Zugriff zu steuern. Zudem werden kaum modifizierte respektive zusätzliche Befehle benötigt.
Die Konfiguration von AppArmor erfolgt über sogenannte Profile. Im Falle von OpenSuse 10.1 können diese komfortabel über das Systemwerkzeug Yast, das Kommandozeilenwerkzeug genprof oder von Hand konfiguriert werden. Abgelegt werden die Profile in
/etc/apparmor.d respektive
/etc/apparmor/profiles/extras.
AppArmor teilt die Programme in zwei Klassen ein: vertrauenswürdige Programme und nicht vertrauenswürdige. Die Unterscheidung ist dabei ganz einfach: Vertrauenswürdig sind alle Programme, für die kein AppArmor-Profil vorhanden ist. Existiert ein Profil, ist das Programm nicht vertrauenswürdig, worauf AppArmor eine strenge Policy darauf anwendet, die alles unterbindet, was nicht explizit erlaubt ist.
Profile bestehen aus simplen Konfigurationsdateien. Wie man im Kasten sieht, ist die Syntax für die Konfigurationsdateien recht verständlich. Die erste #include-Direktive importiert ein paar globale Definitionen, bevor die Konfiguration des SMTP-Clients von Postfix beginnt, der mit seinem absoluten Pfad referenziert werden muss. Die nachher folgenden #include-Statements fügen Definitionen aus generischen Profilen ein, die über mehrere spezifische Profile hinweg benötigt werden. Richtig interessant wird es bei den Capability-Direktiven. Capabilities teilen die Rechte, welche Root hat, in mehrere Aktionen auf, die einzeln an die Programme vergeben werden können. So kann einem Programm beispielsweise gestattet werden, den Eigentümer einer Datei zu ändern, ohne dass es selber komplette Root-Rechte braucht.
Unter den Capability-Definitionen folgen die Pfade, auf die das Programm zugreifen kann. Links wird jeweils der Pfad definiert, während rechts mit den Buchstaben die Rechte angeben werden. R erlaubt beispielsweise Lesen, w Schreiben oder x Ausführen. Weitere Bits wie i weisen AppArmor an, das aktuelle Profil auf ein Programm, das ausgeführt werden darf, zu vererben. Pfade können mit regulären Ausdrücken erweitert werden, was insbesondere bei Prozessen, die grössere Mengen von Dateien mit verschiedenen Namen anlegen, praktisch ist.
Allerdings werden die meisten Anwender wohl kaum selber ihre Profile schreiben, da Novell eine Reihe von hilfreichen Tools zum AppArmor-Management in Yast integriert hat. Besonders praktisch ist dabei der Assistent zum Hinzufügen von Profilen. Nachdem man ein Programm ausgewählt hat, für das man ein Profil erstellen möchte, werden dessen Aktionen im Normalbetrieb überwacht. Nachher werden die Aktionen vom AppArmor-Wizard ausgewertet, und man kann die Aktionen einzeln erlauben, an die eigenen Bedürfnisse anpassen oder verbieten. Nach dem Beenden des Wizard wird das Profil scharf geschaltet und beim nächsten Start des jeweiligen Programms benutzt. Sollte man gewisse Aktionen unterbunden haben, die das Programm unbedingt benötigt, oder vergessen haben, sie beim Erstellen des Profils überhaupt zu erfassen, existiert ein Update-Wizard, der beim Aktualisieren der Profile hilft. Zudem zeigt das Kommandozeilen-Werkzeug unconfined eine Liste der Prozesse an, die ohne AppArmor-Profil am Netzwerk hängen.
Für erste Experimente bietet es sich an, ein einfaches Programm wie GNU Diff auszuwählen und den Zugriff auf einen bestimmten Ordner zu beschränken. Führt man dort nun GNU Diff mit dem Profil aus, arbeitet es wie bisher problemlos. Wechselt man aber in einen anderen Ordner, quittiert es den Dienst mit der Meldung, dass diese Operation nicht erlaubt sei.
Das Verhalten von AppArmor lässt sich über die jeweiligen Logs mit dem Kommandozeilen-Utility logprof respektive über den ebenfalls in Yast integrierten Bericht-Generator nachvollziehen und über das virtuelle Dateisystem secu-rityfs in /sys/kernel/security/apparmor kontrollieren.
AppArmor unterstützt für einige Applikation nicht nur ein einzelnes Hauptprofil, sondern auch eine beliebige Anzahl Subprofile. Diese werden in AppArmor-Nomenklatur Hats genannt und können mit speziell gepatchter Software verwendet werden. Für Apache existiert beispielsweise das Modul mod_apparmor. Dieses ist in der Lage, je nach Virtual Host oder URI in ein anderes Profil zu wechseln oder, sollte keines vorhanden sein, ein Standard-Profil zu verwenden. Damit lässt sich der Aktionsradius von PHP- oder Perl-Scripts drastisch einschränken, womit sich recht zuverlässig Exploits unsicherer Scripts eindämmen respektive unterbinden lassen.
Trotz der vielen Vorteile bringt AppArmor auch einige Nachteile respektive Probleme mit sich. Dies beginnt bereits bei der Nutzung von LSM, das bei Sicherheitsexperten wie grsecurity-Autor Brad Spengler oder RSBAC-Programmierer Amon Ott einen schlechten Ruf geniesst. Sie monieren unter anderem, dass LSM es Angreifern einfacher macht, Rootkits ins System einzuschleusen, die sich überhaupt nicht entdecken lassen. Ein weiteres Problem besteht im Pfad-basierenden Kontrollmechanismus, der sich beispielsweise mit Hardlinks austricksen lässt. Denn ein Angreifer kann mit Hilfe eines Hardlinks ein Binary, auf das ihm AppArmor den Zugriff verwehrt, an einem anderen Ort verfügbar machen, an dem AppArmor den Zugriff gestattet. Hier gilt es, entsprechende Massnahmen zu treffen, dass Angreifer respektive nicht vertrauenswürdige Prozesse beispielsweise keine Hardlinks erzeugen können. Ausserdem muss wie bei allen Policy-Systemen darauf geachtet werden, dass ein Angreifer nicht irgendwann aus der AppArmor-Domäne fällt, wenn beispielsweise ein Profil den Zugriff auf ein bestimmtes Programm nur mit einer Policy erlaubt, ein anderes Programm im aktuellen Profil den Zugriff auf dieses Programm aber auch ohne Policy gestattet. So könnte ein Angreifer mit einem Umweg über das andere Programm dennoch auf den von ihm gewünschten Pfad zugreifen.
|
