Neues Sicherheitssystem für Linux: AppArmor schützt vor Lücken

Schild-Kröte

---

Nichts ist so gut dass es nicht noch besser sein könnte -- das haben sich wohl die AppArmor-Entwickler gedacht und für Linux eine zusätzliche Sicherheitsschicht entworfen. Suse Linux 10.1 integriert diesen Schutzschild bereits.

---

Achim Leitner

Der beste Schutz vor Internetangreifern ist perfekt sichere Software, die genau das erledigt, was sie soll, und sich von niemandem austricksen lässt. Dummerweise ist nichts perfekt -- und schon gar keine Software. Folglich haben sich Computer-Sicherheitsexperten viele Tricks einfallen lassen, um die Bösewichte vom eigenen Computer fernzuhalten und, wenn das nicht gelingt, den Schaden zu begrenzen.

Eine recht neue Technik, die dieses Ziel verfolgt, nennt sich AppArmor ([1-3] und Kasten "Historie"). Novell integriert dieses System in Suse Linux 10.1 und aktiviert es per Default sogar. Die Grundidee hinter AppArmor ist nicht neu, erst die Art der Umsetzung macht den Charme dieses Produkts aus.

Historie

AppArmor war ursprünglich unter dem Namen Subdomain bekannt, ein kommerzielles Produkt der Sicherheitsfirma Immunix. Novell hat Immunix Mitte 2005 gekauft, Subdomain in AppArmor umgetauft und Anfang 2006 unter die GPL gestellt. Für Suse Linux 10.0 existieren Pakete und Patches; in Version 10.1 hat Novell ihre neue Errungenschaft gleich eingebaut. Immunix war auch maßgeblich an der Entwicklung der LSM-Schnittstelle (Linux Security Modules) beteiligt. Neben AppArmor nutzen etliche Sicherheitssysteme wie das konkurrierende SELinux die LSM-Technik, um ihre Kontrollfunktionen in die passenden Stellen des Kernels einzuklinken.

Die Sicherheit eines Linux-Systems ist beinahe militärisch in vielen Verteidigungslinien organisiert. Die Firewall verhindert Zugriffe auf Serverdienste, die gar nicht öffentlich zugängig sein sollen. Der Kernel isoliert die Prozesse voneinander, die Benutzer haben nur eingeschränkte Zugriffsrechte, Programmierer achten auf sicheren Entwurf ihrer Programme, Distributoren wählen Software auch nach deren Sicherheitseigenschaften aus und untersuchen sie auf Fehler.

Rest-Löcher

Bleibt bei all dem Aufwand doch ein Lücke unbemerkt, dann übernimmt ein Angreifer üblicherweise die Kontrolle über einen Prozess (also ein gerade laufendes Programm). Dieser Prozess gehört einem Benutzer. Da der Prozess über alle Rechte seines Besitzers verfügt, hat sich der Eindringling automatisch alle Rechte dieses Benutzers verschafft. Schlimmstenfalls ist das Root -- aber auch normale Benutzerrechte reichen für allerlei Unfug.

Ob der Einbrecher über seinen neu erworbenen Zugang private Daten ausspioniert, den Benutzer bei dessen Onlinebankgeschäften austrickst oder ob er im Namen seines Opfers weitere Rechner attackiert und damit das Opfer in juristische Schwierigkeiten bringt -- in jedem Fall fangen die Probleme erst richtig an, sobald der Onlinebösewicht den Rechner geknackt hat.

Keine Privilegien

Dabei muss all das gar nicht sein. Denn: Linux räumt den Programmen eigentlich viel zu viele Rechte ein. Ein Bildbetrachter muss keine Netzwerkverbindung aufbauen, ein Hilfeprogramm braucht keinen Zugang zu den Homeverzeichnissen der Benutzer, und ping verwendet seine Root-Rechte nur, um die speziellen Ping-Netzwerkpakete abzusenden, aber nicht um die Rechte anderer User anzunehmen oder fremde Prozesse zu beenden.

Per Default räumt das Rechtemodell von Linux seinen Prozessen dennoch all diese Fähigkeiten ein. Die Gegenbewegung nennt sich "least privilege": Hat jeder Prozess nur das wirklich nötige Minimum an Rechten, dann erbt auch ein Angreifer nur diese Minimalprivilegien, was seine Aktionen deutlich behindert. Im Idealfall ist die Lohn seiner Mühe nur ein so geringer Satz an Privilegien und Zugriffsrechten, dass er keinen Schaden anrichten kann.

Alternativen

Linux bringt bereits einfache Basistechniken mit, um die Privilegien zu begrenzen: Die Unterscheidung in den allmächtigen Administrator Root und in Normalbenutzer sowie die Dateizugriffsrechte, die der Besitzer einer Datei oder eines Verzeichnisses erteilt. Diese Einteilung ist zwar recht grob, aber vergleichsweise gut zu verstehen.

Das extreme Gegenteil stellen Techniken wie SELinux [4] dar: Sie modellieren enorm detailliert, welche Komponente im System auf welche Weise worauf zugreifen darf. Dafür führen sie Rollen, Typen und Sicherheitsdomänen ein -- zusammen mit einem Regelsatz, den ein einzelner Mensch nicht mehr verstehen kann. Solche Regeln zu vergeben bleibt ausgewiesenen SELinux-Spezialisten vorbehalten; selbst Vollzeit-Administratoren beißen sich daran die Zähne aus.

Einen vernünftigen Mittelweg [5] beschreitet AppArmor: Statt alle Komponenten und jeden möglichen Zugriff zu behandeln, konzentriert es sich auf Prozesse und deren Privilegien. So genannte Profile geben vor, wie sich dieser Prozess im Normalfall verhält, sprich: welche Aktionen er ausführt, welche Programme er startet und auf welche Dateien und Verzeichnisse er zugreift. Seine Rechte sind dadurch weit stärker begrenzt als die seines Besitzers. Ein von AppArmor erfasster Prozess bleibt sogar dann in seinem virtuellen Korsett gefangen, wenn er unter der Benutzerkennung root läuft.

Vorschriftsmäßig

In der Fachsprache übt AppArmor eine so genannte Mandatory Access Control (MAC) aus: Während es beim herkömmlichen Discretionary Access Control (DAC) im Ermessen des Besitzers einer Datei liegt, welche Rechte diese erhält, gibt bei MAC der Regelsatz (oder das Profil in der AppArmor-Sprache) vor, was erlaubt ist. Das Profil stammt vom Administrator.

---

MAC: Mandatory Access Control. Zugriffskontrollsystem, bei dem ein Administrator zentral vorgibt, wer worauf wie zugreifen darf. Der englische Begriff Mandatory bedeutet "verbindlich" oder "zwingend".
DAC: Discretionary Access Control. Im Gegensatz zur MAC entscheidet jeder Besitzer einer Datei selbst über deren Zugriffsrechte. Discretionary bedeutet hier "im Ermessen".

---

Die Liste der zulässigen Zugriffe klebt bei AppArmor nicht an der Zieldatei, sie steht vielmehr in einem Profil, das für je ein Programm gilt. Dabei gelten diese Zugriffsbeschränkungen zusätzlich zu den normalen Linux-Rechten. Sprich: Sowohl die Zugriffsrechte einer Datei als auch AppArmor müssen eine Aktion gestatten, damit der Kernel sie ermöglicht und nicht blockiert.

Abb. 1: Suses YaST bringt sieben Module mit, um AppArmor zu konfigurieren und dessen Sicherheitsmeldungen zu analysieren.

AppArmor in YaST

Wenn Sie sehen wollen, welche Programme bereits über ein AppArmor-Profil verfügen, starten Sie am besten das entsprechende YaST-Modul:

1. Wählen Sie im K-Menü System / YaST (Kontrollzentrum), geben Sie das Root-Passwort ein und wählen Sie dann in YaST den Bereich Novell AppArmor (Abbildung 1).

2. Starten Sie das Modul Profil bearbeiten. Es erscheint ein Fenster mit einer Liste aller vorhandenen Profile (Abbildung 2).

3. Die genauen Einstellungen eines Profils sehen Sie, wenn Sie eines auswählen (zum Beispiel /bin/ping) und auf Weiter klicken (Abbildung 3).

4. Um einzelne Einträge zu ändern, markieren Sie diese und klicken auf Edit Entry. Haben Sie die Zeile mit /etc/modules.conf markiert, dann erscheint folgendes Fenster:

Hierin könnten Sie bequem die Zugriffsrechte auf die angegebene Datei ändern. Sie sollten die Profile aber unverändert lassen: Stimmen die Einträge nicht mehr, kann das zu unerwarteten Fehlfunktionen führen.

Das Ping-Beispiel zeigt ein recht einfaches Profil. Es beginnt mit drei so genannten Abstraktionen: #include abstractions/base bindet eine Reihe von erlaubten Zugriffen ein, die jedes Programm braucht, um überhaupt zu starten. Dazu gehören zum Beispiel wichtige Basisbibliotheken. Danach folgen die Sammlung für Konsolenprogramme und eine für den Namensdienst: Ping ermittelt per Nameservice die IP-Nummer zu einem Rechnernamen.

Die Rechtesammlungen oder Abstraktionen sind recht praktisch: Sie halten die Profile übersichtlich und ersparen dem Sicherheitsexperten viel lästige und fehlerträchtige Mehrfacharbeit.

Abb. 2: Unter "Profile bearbeiten" listet YaST alle bereits vorhandenen AppArmor-Profile auf. Wie viele AppArmor-Module steht auch dieses nur in Englisch zur Verfügung.

Abb. 3: Das AppArmor-Profil für Ping gibt diesem Programm einige typische Sammlungen von Rechten (nach der "#include"-Anweisung), sowie zwei so genannte Capabilities (siehe gleichnamigen Abschnitt) und Zugang zu zwei Dateien.

Capabilities

Das Ping-Programm läuft mit Root-Rechten, um spezielle Netzwerkpakete erstellen zu können, die ein gewöhnlicher User nicht senden darf. Linux und AppArmor unterteilen die vielfältigen Root-Rechte in eine Vielzahl einzelner Fähigkeiten, so genannter Capabilities. Von all den möglichen Root-Fähigkeiten braucht Ping nur CAP_NET_RAW (für die Ping-Netzwerkpakete) sowie CAP_SETUID, um als Set-UID-Programm mehr Rechte zu erhalten als der aufrufende Benutzer.

Die letzten beiden Zeilen in Abbildung 3 zeigen Zugriffsrechte für einzelne Dateien. Die Syntax orientiert sich an der Linux-typischen Darstellung. Der erste Eintrag gestattet dem Ping-Programm, überhaupt zu laufen: Die Datei /bin/ping erhält Lese (r)- und Ausführungsrechte (x) sowie das Inherit-Flag (i). Mit letzterem erbt der laufende Prozess das Profil, das zu dieser Datei gehört. Interessanter ist die letzte Zeile: Ping darf die Datei /etc/modules lesen.

In diesem YaST-Modul ist zu sehen, dass Novell die Integration etwas mit der heißen Nadel gestrickt hat: Trotz deutscher Spracheinstellung nervt eine wilde Mischung aus Deutsch und Englisch. Währen manche Bereiche noch gar nicht übersetzt sind, wechselt in manchen Fenster die Sprache von Zeile zu Zeile. Solche Schlampereien stärken nicht gerade das Vertrauen in ein Sicherheitssystem.

Lernfähig

Wer neue Profile anlegen will, muss bei AppArmor nicht alles von Hand machen. Novell liefert einen Wizard mit: das YaST-Modul Assistent zum Aktualisieren von Profilen.

1. Der Assistent fragt beim Start nach der Programmdatei, für die Sie ein Profil erstellen wollen.

2. Anschließend fordert YaST Sie auf, das zu schützende Programm zu starten.

3. Arbeiten Sie mit diesem Programm und führen Sie dabei alle Aktionen aus, die AppArmor als erwünschte Handlung erkennen und künftig auch gestattet soll.

4. Nach Ende dieses Prozesses analysiert AppArmor seine Logdatei und fragt für jeden Eintrag, ob Sie ihn erlauben wollen (Abbildung 4). Sie haben dabei oft die Wahl zwischen etlichen Alternativen. Zum Beispiel erkennt der Assistent, wenn Aktionen zu einer Abstraktion gehören, und fragt, ob Sie die komplette Rechtesammlung einbinden oder nur diesen einzelnen Zugriff gestatten wollen.

Abb. 4: Der Profilassistent vereinfacht das Anlegen neuer Profile für bislang ungeschützte Programme. Allerdings ist fundiertes Hintergrundwissen nötig, um die richtige Entscheidung zu treffen.

Aber Vorsicht: So einfach wie Novell seine Benutzer glauben machen will, ist das Anlegen neuer Profile nicht. Die richtigen Entscheidungen zu treffen, erfordert viel Hintergrundwissen. Zu der noch recht einfachen Frage, ob eine Aktion Teil einer Abstraktion ist, gesellt sich noch die Wahl passender Jokerzeichen bei Dateinamen.

Doch nur Experten

Überlassen Sie das Anlegen oder Ändern von Profilen lieber Linux-Experten und gestandenen Administratoren. Denn: Sind die Regeln in den Profilen zu lax, verkommt der AppArmor-Mantel zum löchrigen Fetzen, auf den Sie auch verzichten können. Zu eng gefasste Profile schnüren dagegen das Programm so weit ein, dass es nicht mehr korrekt funktioniert.

Gerade in dieser Situation ist die Fehlersuche schwer: Resultiert ein Programmabsturz aus einem gewöhnlichen Programmierfehler, oder hat AppArmor eine Aktion untersagt und das geschützte Programm damit nicht gerechnet? Oder: Ist vielleicht sogar gerade ein Angriff im Gange? AppArmor will mit detaillierten Berichten über Schutzverletzungen zwar helfen, aber nur erfahrene Linux-Spezialisten verstehen diese Meldungen.

Schutz für alle

Was bleibt, ist der Zusatzschutz, den Novell mit der AppArmor-Defaultkonfiguration seiner Suse-Distribution spendiert hat. Viele wichtige Programme sperrt AppArmor in ein enges, aber ausreichend dimensioniertes Korsett. Einbrechern stemmt sich damit eine weitere Verteidigungslinie entgegen, während AppArmor den Benutzer bei seiner Arbeit mit Linux nicht weiter behelligt. (fjl)

Infos

[1] Suse-Informationsseite zu AppArmor: http://de.opensuse.org/AppArmor [2] AppArmor-Artikel mit Beispiel zum Erstellen eines Profils: Ralf Spenneberg, "Goldene Käfige", LinuxUser 03/2006, S. 58 ff. [3] Hintergrundartikel zur Funktionsweise von AppArmor: Ralf Spenneberg, "Allgemeine Schutzimpfung", Linux-Magazin 06/2006, S. 44 ff. [4] Artikel zu SELinux: Ralf Spenneberg, "Verstärkte Sicherheit", Linux-Magazin 06/2006, S. 36 ff. [5] Diskussion über die Unterschiede zwischen AppArmor und SELinux: Achim Leitner, Crispin Cowan und Daniel Riek, "Der stärkste Schutz", Linux-Magazin 06/2006, S. 50 ff.

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.