Security Enhanced Linux oder App Armor: Welche Rüstung besser auf den eigenen Bedarf passt und wie gut sie feindliche Attacken abwehrt, darüber lässt sich trefflich streiten. Genau dazu hat das Linux-Magazin zwei prominente Verfechter aufgefordert.

Novell und Red Hat liefern sich derzeit eine wortreiche Auseinandersetzung um das beste Schutzsystem für Linux. Während Red Hat seit Jahren auf SE Linux setzt, schickt Novell nach dem Kauf von Immunix eine eigene Lösung ins Rennen: App Armor. Beide unterstehen der GPL, wollen Linux sicherer machen, die Folgen von Attacken abmildern und dem Admin mehr Kontrolle über die Rechte seiner Applikationen geben (siehe die jeweiligen Artikel im Heft).

Das Linux-Magazin gab Vertretern beider Lager die Gelegenheit, sich zu ihrer Motivation zu äußern. Zunächst präsentiert Crispin Cowan die Vorteile von App Armor. Im Anschluss erklärt Daniel Riek, warum Red Hat bei SE Linux bleibt.

Crispin Cowan, Novell

App Armor [1] verfolgt wie auch SE Linux das Ziel, die Systemsicherheit zu erhöhen. Im Detail unterscheiden sich ihre Ziele aber: App Armor sichert einzelne Applikationen vor latenten Macken. Es schützt das ganze System vor bestimmten Bedrohungen, etwa Angriffen über das Netzwerk, indem es alle netzwerkfähigen Programme einzeln unter seine Fittiche nimmt.

Kontrollwahn

SE Linux will dagegen das komplette System kontrollieren und berücksichtigt Eigenschaften wie den Informationsfluss. Als Kehrseite ist die hohe Komplexität der Software zu sehen. Die ursprünglich ausgelieferte Strict Policy stellte sich als zu strikt und damit unbenutzbar heraus. In der Folge näherte sich SE Linux dem App-Armor-Modell an: Die neue Target Policy simuliert das Zugriffskontrollmodell von App Armor, beide orientieren sich an den Applikationen.

Bei App Armor beschränkt der Admin seine Applikationen anhand vertrauter Kriterien. Er nennt das zu schützende Programm und die Files, auf die es zugreifen darf, mit ihrem absoluten Pfadnamen. Die Zugriffsmodi tragen die geläufigen Kürzel »r« für Lesen und »w« für Schreiben. Für Dateisammlungen sind traditionelle Shell-Metazeichen zuständig, beispielsweise gestattet der Eintrag »/home/*/public_html/**.html r« den Lesezugriff auf ».html«-Dateien in den »public_html«-Ordnern aller Anwender.

Etiketten im Filesystem

SE Linux klebt dagegen Labels an alle Dateien und Prozesse und definiert eine Security Policy, die festlegt, welches Label wie welche anderen Labels aufruft. Zugriffskontrolle mit Etiketten ist eine etablierte 70er-Jahre-Technik, sie behindert allerdings generell die Usability:

• Die Labels im Filesystem anbringen und eine Security Policy
  schreiben sind zwei getrennte Schritte. Dabei entsteht eine
  gegenseitige Abhängigkeit: Jeder der beiden Schritte bedingt
  den anderen.
• Einige Applikationen (etwa »tar«) wissen mit den
  Labels nichts anzufangen. Beim Speichern und Wiederherstellen gehen
  die Labels der Dateien verloren.
• Auch NFS kennt keine Labels, ein per NFS gemountetes
  Dateisystem erhält ein einziges Label für seinen
  kompletten Inhalt. Damit sind nur Alles-oder-nichts-Policies
  möglich: Entweder ein Applikation darf überall im NFS
  lesen oder nirgends.

Einfachheit ist die Seele der Sicherheit: Je komplexer ein System, desto wahrscheinlicher ist es auch mies konfiguriert. Schlimmer noch: Eine unverständliche Policy ist keine Policy, sondern eine Black Box, von der ein Admin zwar hofft, dass sie ihm etwas Schutz bietet, sicher ist er sich aber nicht.

App Armor ist beträchtlich einfacher als SE Linux. Das mag eine subjektive Einschätzung sein. Ein Video [2] zeigt, wie ein Vortragender auf der Fosdem vor den Augen seines Publikums eine Policy für Apache in gerade mal fünf Minuten erstellt. Ein weiterer Beleg: App Armor begnügt sich mit 133 Zeilen für sein Apache-Profil, während SE Linux dafür 826 Zeilen braucht. Magnus Runesson berichtet, dass er App Armor schneller auf Ubuntu Linux portiert hatte, als er benötigte, um eine einzelne SE Linux Policy zu verstehen und zu ändern.

Einfach besser

Trotz seiner Einfachheit enthält App Armor sogar Schutzmechanismen, die SE Linux fehlen. Dazu zählen Subprozess-Einschränkungen, bei denen App Armor Teile eines Prozesses unterschiedlich behandelt. Die SE-Linux-Entwickler haben erst vor kurzem einen ähnlichen Mechanismus nachgerüstet. Allerdings bringt App Armor ein Apache-Modul mit, das dieses Feature auch tatsächlich verwendet. Damit sind Profile möglich, die für einzelne PHP-Seiten gelten oder für Perl-Skripte, die per Mod_perl als Teil des Apache-Prozesses laufen. Dieses Feature ist einzigartig.

Crispin Cowan

Dr. Crispin Cowan (Abbildung 1) war CTO und Gründer von Immunix. Seit dem Aufkauf durch Novell ist er als Architekt zuständig für die Sicherheit der Linux-Plattform und -Applikationen, speziell für das von Immunix stammende App Armor. Bei Immunix entwickelte er etliche bekannte Host-Sicherheitssysteme wie Stackguard (GCC mit Schutz vor Buffer Overflows) und das LSM-Interface (Linux Security Modules) in Linux 2.6. Crispin Cowan ist auch einer der Erfinder der Time-to-Patch-Methode, die eine Einschätzung abliefert, zu welchem Zeitpunkt es sicher ist, ein Security-Patch einzuspielen. Vor seiner Zeit bei Immunix war er Professor am Oregon Graduate Institute, Department of Computer Science and Engineering. Abbildung 1: Crispin Cowan: “Einfachheit ist die Seele der Sicherheit. Während SE Linux die Ansprüche der NSA erfüllt, ist App Armor für Linux-Normaluser gemacht.”

Änderungen unnötig

App Armor erfüllt seine Aufgabe unsichtbar für die Applikation. Nur für Subprozess-Einschränkungen braucht es die Hilfe des geschützten Programms, was beispielsweise ein Modul oder ein Plugin erledigt. Sollte App Armor im laufenden Betrieb abrupt und komplett ausfallen, wird das System trotzdem unverändert weiterlaufen, es ist lediglich anfälliger für Angriffe.

SE Linux kann dagegen nur einige seiner Funktionen auf unveränderte Programme anwenden. Das volle Feature-Set bedingt neu gelinkte Applikationen (mit Libselinux). Das klappt zwar mit Open-Source-Software, bereitet bei proprietären Programmen jedoch Probleme. Gerade im Enterprise-Umfeld sind diese aber häufig anzutreffen.

App Armor bevorzugt

Qualitativ hochwertigen Schutz für Linux-Systeme liefern sowohl App Armor als auch SE Linux. Letzteres scheint aber mit beliebig komplexen Policies auf Kosten der Usability mehr auf die Ansprüche der NSA gemünzt zu sein. Produkte mit mangelnder Usability verschmähen die meisten Anwender.

Das Design von App Armor ist dagegen für den Normaluser gemacht, egal ob er Linux privat einsetzt oder ein Enterprise-System administriert. Wer es selbst probieren will: App Armor ist verfügbar für Slackware, Ubuntu, Gentoo, Red Hat sowie Pardus und integriert in alle neuen Ausgaben von Suse Linux für x86, x86-64, Itanium, Power und Z-Series.

Daniel Riek, Red Hat

SE Linux sorgt im Kernel für strikte MAC-basierte Zugriffskontrolle (Mandatory Access Control). Es minimiert die Folgen (Impacts) erfolgreicher Angriffe, garantiert die Vertraulichkeit von Daten und erfüllt dank kontextabhängiger Domainwechsel auch komplexe Sicherheitsanforderungen.

Die erste Firma, die SE-Linux-Unterstützung in einem kommerziellen Produkt ankündigte, war Novell. Freilich ohne ernsthaft in der Praxis einsetzbare Policy. Zu dem Zeitpunkt war die Policy nicht für den breiten Markt geeignet: zu streng, zu starke Einschränkungen für User-Anwendungen, insgesamt übertrieben sicher. Es war Red Hat, die zuerst mit einem ausgereiften und in der Praxis einsetzbaren Produkt auf den Markt kam. Bei jeder Installation von Red Hat Enterprise Linux 4 und bei Fedora ist SE Linux per Default für zentrale Netzdienste aktiv.

Breite Community

Um SE Linux existiert eine große aktive Community. Neben nicht-kommerziellen Anwendern und Anbietern gehören dazu Red Hat, IBM, HP, NSA, DOD, Tresys und Trusted Computing Systems. Gemeinsam verbessern sie die Policies, entwickeln eine leistungsfähige Auditing-Infrastruktur und Tools für die Policy-Entwicklung [4], helfen beim Troubleshooting und beraten die Anwender.

Novell hingegen verabschiedete sich vergangenes Jahr von SE Linux und begann das von Immunix übernommene App Armor als einfachere Alternative zu favorisieren. Statt in die Kooperation innerhalb der OSS-Community zu investieren und SE Linux einfacher nutzbar zu machen, entschied sich Novell dafür, die Sicherheitsarchitektur in Linux aufzuspalten (das ist ein Fork) und die Entscheidung auf Entwickler und Anwender abzuwälzen. Ein Vorgehen, das nicht nur Dan Walsh, Leiter der SE-Linux-Entwicklung bei Red Hat, an das klassische Unix-Problem erinnert [5].

Zur Einfachheit von App Armor führt deren FAQ aus: “Sicherheitsprofile entwickeln ist eine überschaubare Aufgabe selbst für Neulinge, während Power-User die Flexibilität erhalten, die sie für exakt abgestimmte Profile brauchen.” Aber wer möchte seine Kreditkartendaten schon auf einem Server gespeichert sehen, dessen Sicherheits-Policy von einem Neuling (Novice User) mit Yast und dem App-Armor-Lernmodus erstellt wurde? Red Hat konzentriert sich dagegen auf den Unternehmenseinsatz. Softwarehersteller liefern die verifizierten SE Linux Policies, die die Kunden mit geprüften Parametern konfigurieren.

Tatsächlich ist App Armor einfacher zu konfigurieren, weil es eine wesentlich kleinere Klasse von Sicherheitsproblemen adressiert. Die FAQ streicht sogar als Vorteil von App Armor heraus, dass es im Gegensatz zu SE Linux nicht die Vertraulichkeit von Daten garantiert, und behauptet, diese Funktion sei nur für Geheimdienste interessant. Kein Wort über Kreditkartendaten, Kundendaten, Patientendaten, Buchhaltungsdaten, Basel II und Sabranes Oxley Compliance …

Irreführende Behauptung

Auch die Behauptung, für SE Linux sei es nötig, Applikationen neu zu kompilieren, ist irreführend: Bei SE Linux hängt der Security-Kontext nach dem Start eines neuen Prozesses davon ab, wer den Prozess aus welchem Kontext heraus startet. Dafür sind keinerlei Änderungen an Applikationen notwendig und die Sicherheitskontexte bleiben klar abgegrenzt. Nur bei wenigen Programmarten ist eine Modifikation nötig.

Mit den Subprozess-Einschränkungen von App Armor lassen sich etwa PHP-Skripte mit Mod_php in einem anderen Kontext ausführen als Apache selbst, obwohl sie im selben Prozess ablaufen. Die FAQ erwähnt, dass dies nur mit dem speziell angepassten Apache von Novell funktioniert. Rekompilieren ist also auch bei App Armor gelegentlich nötig.

Daniel Riek

Daniel Riek (Abbildung 2) ist seit Anfang 2006 Product Manager für Red Hat Enterprise Linux. Er kam Mitte 2003 zu Red Hat. Vor seinem Wechsel in die Produktentwicklung widmete er sich als Solution Architect der Kundenberatung im Pre Sales. Bereits während seines Informatik-Studiums an der Universität Bonn gründete Riek ID-PRO, einen Internet- und GNU/Linux-Dienstleister der Dotcom-Ära. 2001 wechselte er zum französischen Free-Software-Dienstleister Alcove, wo er für das Deutschlandgeschäft zuständig war und Kunden aus dem IT- und Banken-Umfeld betreute. Riek war viele Jahre Mitglied im Vorstand des Linux-Verbandes LIVE und auch als Pressesprecher der Organisation tätig. Abbildung 2: Daniel Riek: “Ich möchte meine Kreditkartendaten nicht auf einem Server gespeichert sehen, dessen Policy ein Neuling mit Yast und App Armor erstellt.”

Das Konzept hat einen massiven Nachteil: Nichts hindert Schadcode, den ein Angreifer im PHP-Kontext einschleust, daran, später im Apache-Kontext abzulaufen. Es handelt sich schließlich um denselben Speicherbereich. Der vom Exploit betroffene Code kann nicht selbst die Sicherheit garantieren! Das Szenario ermöglicht daher eine Rechte-Eskalation – so was ist ein Bug, kein Feature.

Label contra Pfadname

Ähnlich sieht es mit dem Filesystem-Argument aus: SE Linux benutzt Security Label, die es in den Extended Attributes für Objekte im Dateisystem speichert. Novell sieht darin eine Erweiterung, die lediglich in bestimmten Dateisystemen unterstützt wird. In der Tat ist dies jedoch ein Standardfeature, das einigen Dateisystemen bisher fehlt, und damit eher ein Argument gegen das von Novell favorisierte Reiser-FS.

App Armor verwendet in seinen Profilen Pfadnamen. Die eignen sich nicht, um Sicherheit zu garantieren: Während die an Inodes gebunden Security Labels bei SE Linux konkrete Objekte im Dateisystem bezeichnen, arbeiten App Armors Pfadnamen auf einer abstrakten Schicht, die nicht notwendigerweise der Realität im Dateisystem entspricht. Symbolische Links sind ein einfaches Beispiel für die vielfältigen Probleme. Ein Objekt kann unter mehreren Pfadnamen auftauchen und dabei verschiedene Rechte erhalten. Fraglich ist, ob das noch als Mandatory Access Control gelten darf.

Eine Frage der Flexibilität

Die Behauptung schließlich, App Armor sei flexibler als SE Linux, entbehrt jeder Grundlage. Zugegeben eine App-Armor-Konfiguration lässt sich schneller anpassen – weil sie ein weniger sicheres System beschreibt. Mit Flexibilität hat dies nichts zu tun. Im Gegenteil: Das eindimensionale Profilkonzept von App Armor ist nicht mit dem Niveau an Sicherheit und Anpassbarkeit vergleichbar, das SE Linux mit seinen dynamischen Security-Kontextübergängen bietet. Ein Programm kann mit unterschiedlichen Rechten laufen, je nachdem, wer es aus welchem Kontext heraus aufruft. Damit sind äußerst flexible Sicherheitsrichtlinien möglich.

SE Linux als Architektur eignet sich auch für Security-Konzepte jenseits von MAC. Dass dies in der Praxis klappt, belegen die Implementierungen von MLS (Multi-Level Security) und MCS (Multi-Category Security). Beide speichern die Eigenschaften im Dateisystem als Extended Attributes und integrieren sich sauber in die SE Linux Policy.

SE Linux bevorzugt

Die bisher konsequenteste Umsetzung von Zugriffsschutz per Mandatory Access Control in einem Standardprodukt ist SE Linux. Es entspringt einer fundamentalen Einsicht in die Funktionsweise von Attacken auf IT-Systeme und in die Geschichte von IT-Sicherheitsproblemen. Im Wettlauf um den nächsten großen Exploit und den Schutz dagegen sind Hacker immer eine Nasenlänge voraus. Dem sollte die Architektur Rechnung tragen und gewährleisten, dass selbst ein gelungener Hack nicht zu schwerwiegenden Konsequenzen führt.

Die Entscheidung zwischen SE Linux und App Armor ist die Entscheidung zwischen einer umfassenden Sicherheitsarchitektur auf der einen und punktuellen Ad-hoc-Verbesserungen auf der anderen Seite. Den typischen Sicherheitsanforderungen der Anwender von Red Hat Enterprise Linux wird nur das komplexere SE Linux gerecht.