© photocase.com

Gelingt es einem Angreifer, fremde Systeme zu infizieren, erbt er alle Rechte seiner Opfer. App Armor schützt vor den Folgen, indem es die Rechte potenzieller Opfer auf ein Minimum begrenzt. Selbst bei einem Webserver mit PHP-Applikationen trennt App Armor scharf zwischen den Sitzungen.

Novell sieht App Armor [1] als besonders einfach zu konfigurierendes und dennoch wirksames Schutzsystem für Linux. Es konkurriert aus Sicht des Herstellers mit SE Linux, das zwar seit längerem in Suse-Distributionen enthalten ist, doch am chronischen Fehlen der nötigen Richtlinien (Policies) leidet. Während SE Linux eine vergleichsweise schwer zu konfigurierende, dafür aber umfassende MAC-Zugriffskontrolle implementiert (Mandatory Access Control), konzentriert sich App Armor darauf, einzelne Applikationen in ihrem Wirkungskreis zu beschränken.

Armors Aufgabe

Leider weisen viele Anwendungen Programmierfehler auf. Besonders anfällig sind Webapplikationen: Die meist individuell entwickelte Software stammt nicht von Sicherheitsspezialisten, ist aber über das Netz weltweit erreichbar und damit ein ideales Angriffsziel. Findet ein Einbrecher einen Programmierfehler in der Anwendung, kann er sie meist für seine Zwecke missbrauchen und sich Zugang zum System verschaffen.

Auf Umwegen zu Root

Selbst wenn der Eindringling nur den Account eines Normalusers erlangt, droht weitere Gefahr: Der Cracker hat direkten Zugang zu allen lokal installierten Programmen. Eine einzige Sicherheitslücke in einem Set-UID-Root-Programm genügt und er übernimmt die Kontrolle.

Den Admins und Webmastern bleibt klassischerweise nur übrig, ihr System ständig auf dem neuesten Stand zu halten und auf allen Ballast zu verzichten, also ausschließlich die unbedingt nötige Software zu installieren. All das schützt aber nicht vor so genannten Zero-Day-Exploits, den Angriffen auf bislang unbekannte Sicherheitslücken.

Aus dieser Misere will App Armor den Admin befreien. Das System überwacht, wie ein Prozess auf Dateien zugreifen möchte. Dabei unterscheidet App Armor lesende und schreibende Aktionen. Zudem kontrolliert es den Einsatz der Root-Privilegien: Je nach Kernel kennt Linux bis zu 29 Privilegien (Capability, Fähigkeit; siehe »man 7 capabilities«). So ist »CAP_KILL« die Fähigkeit von Root, beliebige Prozesse zu beenden, und »CAP_NET_RAW« erlaubt beliebige Netzwerkpakete zu erzeugen. Letzteres braucht zum Beispiel der »ping«-Befehl.

Die Idee, Zugriffe und Aktionen anhand eines Programms und nicht anhand seines Besitzers beziehungsweise Benutzers zu unterscheiden, ist nicht neu. Unter den freien BSD-Systemen und Linux implementiert beispielsweise auch Systrace ([7], [8]) von Niels Provos dieses Prinzip. Während Systrace – dem Namen entsprechend – Systemcalls überwacht, benutzt App Armor die LSM-Hooks (siehe Kasten “Immunix”).

Einsatz unter Linux

Novell liefert App Armor bei den kommerziellen Distributionen Suse Linux 10.0 und SLES 9 SP3 mit (Suse Linux Enterprise Server 9, Service Pack 3). Die GPL-Variante fließt auch in Open Suse 10.1 ein. Für Open Suse 10.0 ist die Installation möglich, aber aufwändig, da sie ein Kernelpatch voraussetzt. Laut Mailingliste [2] könnten sogar Ubuntu und Fedora in Zukunft App Armor unterstützen. Die grafische Oberfläche setzt derzeit allerdings Yast 2 voraus.

Auf Novell Forge [3] stellt die Firma etliche Pakete bereit. Die RPMs für die Alphaversion von Open Suse 10.1 funktionieren auch auf 10.0. Zusätzlich ist ein Kernel mit App-Armor-Unterstützung erforderlich. Das klappt am besten mit einem Originalpaket vom Kernel-Repository [4], zum Beispiel Linux 2.6.15 zusammen mit den Kernelpatches »aa_2.0-2.6.15.patch« und »aa_namespace_sem-2.6.15.patch« [5]. Beim Konfigurieren mit »make oldconfig« genügt es in der Regel, bei allen Fragen mit [Enter] den Defaultwert zu bestätigen. Die Schritte im Einzelnen:

tar xjvf linux-2.6.15.tar.bz2
cd linux-2.6.15
patch -p1<../aa_2.0-2.6.15.patch
patch -p1<../aa_namespace_sem-2.6.15.patch
make oldconfig
make bzImage
make modules
make modules_install
make install
rmdir /subdomain
ln -s /sys/kernel/security/subdomain /subdomain

In neueren Patches wird Novell die Kernelstruktur im Security-FS in »/sys/kernel/security/apparmor« umbenennen. Das Security-FS gehört seit Linux 2.6.14 zum Standardkernel.

Rechtzeitig starten

Die Userspace-Komponente von App Armor startet den Systemdienst und stattet ihn mit der Policy aus. Das Initskript trägt noch den alten Namen Subdomain: »/etc/init.d/boot.subdomain start« lädt das App-Armor-Kernelmodul und aktiviert es. Damit das Modul eine Anwendung behütet, muss es bereits vor der zu schützenden Applikation aktiv sein. Daher startet App Armor sinnvollerweise bereits beim Booten des Systems. Darüber hinaus muss für die Anwendung unter »/etc/subdomain.d« eine Profildatei existieren (in künftigen Distributionen soll das Verzeichnis »/etc/apparmor.d« heißen).

Novell liefert eigene Profile für eine ganze Reihe von kritischen Befehlen und Programmen, darunter Server, Netzwerk-fähige Clients, S-Bit-Tools und Dateibetrachter. Zur Auswahl gehören Apache im Prefork-Modus, OpenSSH, Firefox, Real Player, Ping, Man, Adobe Reader und über 50 weitere Profile, sogar für die Protokolldienste Klogd und Syslogd.

Neue Profile

Wer Profile für Applikationen anlegen will, erhält Hilfe vom Profilassistenten in Yast. Der Assistent muss zunächst nur wissen, für welches Programm er das Profil erzeugen soll. Danach startet der Benutzer das Programm und verwendet es wie gewohnt. Dabei ist es wichtig, sämtliche Funktionen der Anwendung zu nutzen: App Armor lernt in dieser Phase das gewünschte Verhalten der Applikation. Während dieser Lernphase darf kein Angriff möglich sein, denn App Armor gestattet später alle Funktionen, die das Programm dabei verwendet.

Situationsanalyse

Nach dem Beenden der Applikation gilt es, im Profilassistenten die aufgezeichneten Ereignisse zu analysieren. Dabei schlägt der Assistent immer eine Aktion vor. Ruft das zu überwachende Programm zum Beispiel ein weiteres Programm auf (Abbildung 1), dann bleiben vier Wahlmöglichkeiten: »Inherit« bedeutet, dass die neue Anwendung »kdialog« den gleichen Einschränkungen unterliegt wie die gerade analysierte Applikation. Bei »Profile« verfügt das aufgerufene Programm über ein eigenes Profil. Mit »Unconfined« bleibt der neue Prozess ohne Überwachung, »Deny« verweigert den Aufruf.

Abbildung 1: Der Profilassistent unterstützt beim Erzeugen von Profilen. Hier will »kpdf« das Hilfsprogramm »kdialog« starten. Der Assistent stellt vier Aktionen zur Wahl, von »Inherit« bis »Deny«.

Um das Verwalten und Anlegen der Profile zu vereinfachen, kennt App Armor eigene Include-Dateien. Diese fungieren als Abstraktionsbibliotheken, sie enthalten Regeln für klassische Standardoperationen. So gestattet »#include <abstractions/kde>« den Zugriff auf die KDE-Konfigurationsdateien und -Funktionen. Weitere Profile erlauben das Starten der Bash oder die Namensauflösung.

Nach erfolgreichem Abschluss des Assistenten empfiehlt es sich, die Applikation erneut zu starten und ihre Funktion unter App-Armor-Überwachung zu testen. Falls das Programm nun Funktionsstörungen zeigt, steht ein neuer Durchgang mit dem Assistenten an. Der liest das bestehende Profil und aktualisiert es.

Beispielprofil

Ein typisches App-Armor-Profil für Kpdf ist auszugsweise in Listing 1 zu sehen. Nach den Vim-Kommentaren (Suse liefert ein Syntax-Highlighting-Modul für Vim mit) beginnt das Profil mit dem Pfad zu Kpdf – er bestimmt, für welches Programm die Policy gilt. Mit »flags=(complain)« schaltet dieses Profil den Complain-Modus ein, auch Lernmodus genannt. In diesem Zustand warnt App Armor zwar vor Verstößen gegen die Policy, verhindert sie aber nicht. Erst mit »flags=(enforce)« weist App Armor Kpdf in die Schranken.

01 # vim:syntax=subdomain
02 # Last Modified: Sun Jan 22 10:16:55 2006
03 /opt/kde3/bin/kpdf flags=(complain) {
04   #include <abstractions/authentication>
05   #include <abstractions/base>
06   #include <abstractions/bash>
07   #include <abstractions/gnome>
08   #include <abstractions/kde>
09   #include <abstractions/nameservice>
10   #include <abstractions/user-write>
11 
12   / r,
13   /etc r,
14   /etc/X11/.kstylerc.lock rw,
15   /etc/X11/.qt_plugins_3.3rc.lock rw,
16   /etc/X11/.qtrc.lock rw,
17   /etc/exports r,
18   /etc/rpc r,
19 [...]

Die Zeilen 4 bis 10 binden etliche Include-Dateien ein, die Zeilen 12 bis 18 listen die Pfade, auf die der PDF-Betrachter zugreifen darf. Hinter den Pfad- oder Dateinamen steht »r« für lesenden Zugriff, »rw« erlaubt sowohl das Lesen als auch das Schreiben.

Webserver

Besonders interessant ist der Einsatz von App Armor auf einem Webserver. Anders als die bekannten Mandatory-Access-Systeme LIDS, GR-Security, RSBAC oder SE Linux ist App Armor in der Lage, auf einem Webserver virtuelle Hosts mit unterschiedlichen Profilen zu überwachen. Auch in Abhängigkeit des Verzeichnisses kann der Apache Webserver sein Profil wechseln. Diese Funktion bezeichnet Novell als Changehat – vielleicht ein schmunzelnder Seitenhieb auf die rot behütete Konkurrenz.

Wechselnde Hüte

Ohne Unterstützung des Apache schafft es App Armor aber nicht, die jeweiligen Zustände des Webservers zu unterscheiden. Diese Aufgabe übernimmt das von Novell zur Verfügung gestellte Modul »mod_change_hat« (künftig »mod_apparmor«). App Armor erlaubt es jedem Programm, den Security Context zu wechseln. Bislang ist das aber nur beim Apache Webserver realisiert. Das Hauptprofil der Applikation besitzt dazu beliebig viele Subprofile (so genannte Hats). Die Hierarchie ist nur eine Stufe tief, ein Subprofil kann also keine weiteren Subprofile enthalten.

Zum Verwalten der Subprofile bringt Yast grafische Unterstützung mit. Das Kommandozeilen-Äquivalent ist zwar mächtiger, die Konfiguration mit Yast aber einfacher. Der folgende Abschnitt beschreibt die Yast-Variante anhand der Webapplikation Squidfire (Abbildung 2 sowie [6]). Dieses PHP-Skript bereitet die Squid-Protokolldateien durchsuchbar auf. Das mitgelieferte App-Armor-Profil »usr.sbin.httpd2-prefork« verwehrt aber Apache und damit Squidfire jeden Zugriff auf die Logfiles. In »/var/log/audit/audit.log« bestätigt folgende Fehlermeldung das Verbot:

type=APPARMOR msg=audit(1143872666.069:205): REJECTING r access to /var/log/squid (httpd2-prefork(14820) profile /usr/sbin/httpd2-prefork active DEFAULT_URI)

Abbildung 2: Squidfire durchsucht die von Squid protokollierten Zugriffe. Um nur dieser Webapplikation Zugriff auf die Logfiles zu geben, kooperiert Apache per »mod_change_hat«-Modul mit App Armor. So weiß das Sicherheitssystem, welche Webapplikation gerade aktiv ist.

Ein Subprofil soll Squidfire den Zugang gewähren, und zwar ausschließlich zu den Squid-Logfiles. Dies verhindert, dass gewiefte Squidfire-Anwender das Auswertungs-Tool auch auf artfremde Dateien anwenden.

Für Subprofile ist wieder der Yast-Profilassistent zuständig. Beim Aufruf wählt der Admin Apache als Applikation (Abbildung 3). App Armor gestattet diesem Prozess nun sämtliche Aktivitäten und protokolliert sie für die spätere Analyse. Nach etwas Arbeit mit der Anwendung im Browser beendet ein Klick auf »Scan system log for AppArmor events« im Profilassistenten (Abbildung 4) die Lernphase. Bei einer Changehat-fähigen Applikation schlägt der Profilassistent vor, ein neues Subprofil (Hat) anzulegen (Abbildung 5).

Abbildung 3: Der Profilassistent erstellt auch Subprofile, die nur für Teile einer Anwendung gelten. Beim Aufruf ist dazu der Name der Hauptapplikation anzugeben (hier Apache im Prefork-Modus).

Abbildung 4: Nach einem Klick auf »Scan system log for AppArmor events« erzeugt der Assistent einen Profilvorschlag.

Abbildung 5: Der Profilassistent erkennt, dass die Applikation Changehat-fähig ist, und bietet an ein Subprofil für den angeforderten Hat anzulegen.

Enge Grenzen

Bei den folgenden Fragen des Profilassistenten ist Vorsicht angesagt, besonders wenn die Hauptapplikation externe Programme aufruft. Es empfiehlt sich, diese Tools das Profil der aufrufenden Applikation erben zu lassen. Beim Einbinden von Bildern und CSS-Dateien passt auch das Defaultprofil des Apache. Nach den Fragen erzeugt der Profilassistent in der Datei »usr.sbin.httpd2-prefork« ein Subprofil (Auszug in Listing 2).

01 [...]
02 ^/squid/index.php {
03    #include <abstractions/bash>
04    #include <abstractions/nameservice>
05 
06    /bin/bash ixr,
07    /dev/tty rw,
08    /etc/ld.so.cache r,
09    /lib/ld-2.3.90.so ixr,
10    /lib/lib*so* r,
11    /srv/www/htdocs/squid/cache.inc.php r,
12    /srv/www/htdocs/squid/config.inc.php r,
13    /srv/www/htdocs/squid/default_config.inc.php r,
14    /srv/www/htdocs/squid/index.php r,
15    /srv/www/htdocs/squid/parse_squid_row.inc.php r,
16    /tmp/access.log_1.3.0.inc r,
17    /usr/bin/tail ixr,
18    /var/log/apache2/access_log w,
19    /var/log/squid r,
20    /var/log/squid/access.log r,
21 }

Apache-Subprofile unterscheiden sich in der Profildatei per Default anhand der URI (Zeile 2). Dieses Exemplar gestattet der Webanwendung »/squid/index.php« die Bash zu verwenden, einige Systemdateien zu lesen, die Squidfire-Komponenten zu verwenden (Zeilen 11 bis 15) und schließlich die Squid- und Apache-Access-Logs auszuwerten (Zeilen 18 und 20). Das Subprofil zeigt bei genauer Betrachtung sogar gefährliche Aktionen der Applikation: Sie benutzt offenbar Dateien in »/tmp« mit vorhersagbaren Namen (Zeile 16) und verwendet externe Shellkommandos (Bash laut Zeile 6, etwa für Tail, wie Zeile 17 belegt).

Verzeichnisse unterscheiden

Das Modul »mod_change_hat« erlaubt es, Subprofile je nach Virtual Host oder nach »Location«- und »Directory«-Direktive zu trennen. Welche Variante der Admin wünscht, teilt er dem Modul anhand der Direktiven »ImmDefaultHatName« und »ImmHatName« mit. Das Präfix »Imm« erinnert noch an die Immunix-Vergangenheit von App Armor. In neuen Distributionen heißt das Modul »mod_apparmor« und die Schlüsselwörter lauten »AAHatName« und »AADefaultHatName«.

Für jeden virtuellen Server wählt »ImmDefaultHatName« (oder »AADefaultHatName«) ein eigenes Default-Subprofil. Zusätzlich können einzelne Bereiche mit der »Directory«- oder »Location«-Direktive ein eigenes Subprofil erhalten. Die Zuweisung eines Hat an die Squidfire-Webapplikation könnte in der Apache-Konfiguration daher auch so erfolgen:

<Directory "/srv/www/htdocs/squid">
  ImmHatName squidfire
</Directory>

Das Subprofil müsste dann statt »^squid/index.php« den Namen »^squidfire« erhalten (Zeile 2 in Listing 2).

Trennscharf

Insbesondere für Shared Hosting mit mehreren Kunden auf einem Webserver eröffnet App Armor neue Methoden der Serverabsicherung. Erhält jeder Virtual Host einen eigenen stringenten Hat, der nur Zugriffe auf die Dateien dieses Kunden gestattet, bleiben Sicherheitslücken in der Applikation eines Kunden ohne Auswirkung auf die Webapplikationen der anderen Anwender.

Es empfiehlt sich allerdings, die Policies vor ihrem Einsatz auf dem Webserver von Hand zu prüfen oder gleich manuell anzulegen statt sich allein auf den Lernmodus zu verlassen – für Admins dürfte das aber keine größere Hürde sein.

Gut abgeschirmt

App Armor sperrt kritische Applikationen in eine Sandbox. Sie dürfen nur noch auf bestimmte Dateien zugreifen und ausgewählte Befehle starten. Weist die Anwendung eine Sicherheitslücke auf, über die ein Angreifer zum Beispiel eine Shell oder andere Befehle mit den Rechten des Opfers starten möchte, schreitet App Armor ein. Die Applikation darf aus ihrem Käfig nicht ausbrechen. Die Sicherheitslücke verschwindet dadurch zwar nicht, dem Angreifer gelingt es aber nicht mehr, sie (aus seiner Sicht) sinnvoll ausnutzen.

Dieses Prinzip schützt einen Rechner auch vor den Auswirkungen neuer, noch unbekannter Sicherheitslücken. Daher eignet es sich besonders für Programme, die über das Netzwerk erreichbar sind oder die Daten zweifelhafter Herkunft verarbeiten (E-Mails, Bilder, Filme, Office-Dokumente).

Changehat-fähige Applikationen unterscheiden sogar Bereiche innerhalb ihrer Ausführungszeit, in denen unterschiedliche Subprofile gelten. Das ermöglicht insbesondere bei Webservern die Definition von Profilen für spezifische Webapplikationen – je nach URI, Vhost oder Verzeichnispfad gelten dann eigene Regeln. (fjl)