 "AA_photocase_kaefige.jpg")
Niemand ist ohne Fehler – das gilt besonders für Software. In jeder halbwegs komplexen Anwendungen stecken Programmierfehler. Einbrecher nutzen dies: Sie übernehmen die Kontrolle und bringen die Software dazu, etwas anderes zu tun als vom Entwickler gewollt. Kritisch wird das, wenn die Applikation über mehr oder andere Rechte (Privilegien) verfügt als der Einbrecher.
Zum Beispiel benötigt der Befehl ping Root-Rechte. Nur damit darf er das Sonderpaketformat verschicken, das Ping braucht. Mit den Root-Privilegien könnte der Prozess auch beliebigen Unfug anstellen, der Root vorbehalten bleibt. Zwar hält sich ping an die Regeln, zwingt aber ein Angreifer den Prozess unter seine Fuchtel, hält ihn nichts mehr vom restlichen System fern.
AppArmor [1] ändert dies. Statt jedem Root-Programm vollen Zugriff auf das System zu gestatten, beschränkt es die Möglichkeiten. Dabei geht es einen Kompromiss zwischen Wirksamkeit und Komplexität ein: Mit einfachen und durchschaubaren Mechanismen erreicht AppArmor einen hohen Schutz und ähnelt damit Systrace [2]. Mit komplexen Systemen wie SELinux [4] oder RSBAC [5] will es sich nicht messen – deren Konfiguration bleibt höhere Admin-Schule.
Härte zeigen
Trotz aller zusätzlichen Hürden lautet das erste Gebot: Eine nicht vorhandene Sicherheitslücke schützt am besten. Auch auf einem AppArmor-geschützten Rechner sollten Sie – wie auf jeder anderen Installation – nur wirklich benötigte Dienste betreiben, Patches zeitnah einspielen und eine behutsame gestrickte Konfiguration verwenden. Erst bei unbekannten oder noch nicht behobenen Sicherheitslücken und den dazugehörenden Zero-Day-Exploits sollte AppArmor tätig werden.
AppArmor überwacht, auf welche Dateien eine Anwendung auf welche Weise zugreift, und es kontrolliert den Einsatz der Root-Privilegien. Linux unterscheidet je nach Kernel-Version bis zu 29 Privilegien, genannt Capabilities (Fähigkeiten, siehe man 7 capabilities). So ist CAP_KILL die Fähigkeit von Root, beliebige Prozesse zu beenden und CAP_NET_RAW die Capability, beliebige Netzwerkpakete zu erzeugen.
Im Falle des Ping-Befehls im Eingangsbeispiel würde es im Wesentlichen genügen, wenn AppArmor den Einsatz von CAP_NET_RAW erlaubt und beispielsweise CAP_KILL untersagt. Dann dürfte ein Einbrecher keine fremden Prozesse mehr abschließen.
Immunix
Mitte 1995 hat Novell die Firma Immunix gekauft. Sie ist seit Jahren auf die Entwicklung von Sicherheitslösungen spezialisiert. Ihr modifizierter GCC namens StackGuard übersetzt Anwendung so, dass viele Formen von Buffer-Overflow-Exploits scheitern. Dazu benutzt StackGuard einen so genannten Canary. Dieses Frühwarnsystem ermittelt beim Programmstart zufällige Zahlen. Vor jedem Aufruf eines Unterprogramms legt es den Canary-Wert auf den Stack. Hat sich der Wert bis zum Rücksprung verändert, bricht das Programm ab, da es einen Buffer Overflow vermutet. Der Begriff Canary kommt aus dem Bergbau, wo Kanarienvögel als Früherkennung für Kohlenmonoxid dienen.
Immunix war auch maßgeblich an der Entwicklung LSM-Schnittstelle (Linux Security Modules [3]) in Kernel 2.6 beteiligt. Diese Schnittstelle erlaubt es Kernel-Modulen, an den verschiedensten Stellen sicherheitsrelevante Vorgänge zu überwachen. Einige Sicherheitssysteme nutzen LSM, etwa LIDS (Linux Intrusion Detection System [6]) und SELinux (Security Enhanced Linux [4]). Letzteres wurde von der NSA (National Security Agency, USA) entwickelt, es implementiert ein MAC-System (Mandatory Access Control). Der Admin gibt dabei detaillierte Regeln für erlaubte Zugriffe vor. Dieses restriktive Richtlinienwerk kann sogar den allmächtigen Superuser Root und dessen Handlungen überwachen und einschränken.
Während die aktuellen Novell/Suse-Distributionen bereits im Kernel und den benötigten Programmen SELinux unterstützen, fehlen die für die Funktion erforderlichen Richtlinien (Policies).
Ebenfalls von Immunix stammt das AppArmor-System. Novell positioniert nun AppArmor als einfache und wirksame Alternative zu SELinux. Während SELinux eine umfassende und sehr komplexe Konfiguration erfordert, beschränkt sich AppArmor auf einzelne Applikationen und die wichtigsten Aktionen. Ende Januar 2006 gab Novell den Quellcode von AppArmor unter der GPL frei und veröffentlichte umgehend den Code [7] auf der hauseigenen Webseite.
Einsatz unter Linux
In den kommerziellen Distributionen SLES 9 und Suse Linux 10.0 hat Novell das AppArmor-System bereits integriert, damals war AppArmor noch keine freie Software (siehe Kasten "Immunix"). Mit der Freigabe unter der GPL hat Novell angekündigt, AppArmor auch in OpenSUSE 10.1 einzubinden. Wer nicht so lange warten will, kommt auch mit OpenSUSE 10.0 zum Ziel. Allerdings ist die Installation aufwändig: Unter anderem verlangt sie, den Kernel zu modifizieren und neu zu übersetzen. Ungeübten Benutzern ist davon eher abzuraten.
AppArmor-RPMs für OpenSUSE 10.0 stehen auf Novell Forge [7] bereit und zusätzlich auf der Heft-CD dieser Ausgabe. Obwohl Suse/Novell die RPMs für OpenSUSE 10.1 Alpha gebaut hat, funktionieren sie auch unter OpenSUSE 10.0. Die Installation klappt wie üblich per rpm -ivh Paketname.rpm. Zusätzlich braucht der Kernel AppArmor-Unterstützung. Novell stellt Patches bereit [8], die auf einen Originalkernel in Version 2.6.15 passen [9]. Um daraus einen AppArmor-fähigen Kernel zu generieren, laden Sie den Originalkernel sowie die Patches aa_2.0-2.6.15.patch und aa_namespace_sem-2.6.15.patch. Danach folgen die Schritte in Listing 1.
Die Installation auf Nicht-Suse-Systemen wie Debian oder Fedora ist ebenfalls möglich. Allerdings müssen Sie die Quelltextarchive dann selbst übersetzen und auf die grafische Oberfläche verzichten, da diese Yast 2 voraussetzt.
Listing 1
tar xjf 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
Abbildung 1: Mit Yast2 ist es sehr einfach, AppArmor zu aktivieren.
Einem Freund empfehlen
