Sicherheitserweiterungen für Linux

Inhaltsverzeichnis

Das traditionelle Unix-Rechtemodell reicht nicht aus, will man die Systemintegrität eines Linux-Servers auch im Falle von Sicherheitslücken in Anwendungen aufrecht erhalten: Standardmäßig erben Prozesse alle Rechte des Benutzers und Benutzer haben absolute Kontrolle über alle von ihnen erzeugten Objekte. Die Entscheidung, mit welchen Rechten ein Prozess auf ein Objekt (Datei, Verzeichnis, Socket, TCP-Port und so weiter) zugreifen darf, trifft der Kernel aufgrund der Identität des Benutzers, dem der Prozess gehört (Subjekt). So erbt etwa ein per Buffer Overflow im Mail-Server eingeschleuster Shell-Code dessen Zugriffsrechte, im ungünstigsten Fall Root-Rechte.

Die Linux-Anbieter Red Hat und Novell haben diese Schwäche erkannt und Sicherheitserweiterungen in ihre Distributionen integriert, um im Falle eines Einbruchs dem Angreifer die Übernahme des kompletten Servers so schwer wie möglich zu machen. Red Hat setzt dabei auf SELinux, Novell auf AppArmor. Weitere in der Linux-Welt etablierte Ansätze sind grsecurity, Systrace und LIDS. Sie alle legen ein Mandatory-Access-Control-Modell (MAC) zugrunde, in dem vom Benutzer unabhängige Regeln sehr feinkörnig festlegen, was ein Prozess darf.

Mit den Linux Security Modules LSM enthält der Linux-Kernel ein Framework, über das Sicherheitserweiterungen in die Entscheidungsprozesse des Kernels eingreifen können. Dabei dürfen lediglich vom Kernel erlaubte Operationen verboten, nicht jedoch verbotene Aktionen zugelassen werden: Ein LSM-Modul kann die Sicherheitseinstellungen nur restriktiver machen. Die als LSM-Module ausgelegten Sicherheitserweiterungen SELinux und AppArmor haben den Vorteil, dass sie im Gegensatz zu den Kernel-Patches grsecurity, Systrace und LIDS nicht an jede neue Kernelversion angepasst werden müssen.

SELinux

SELinux, entwickelt von dem amerikanischen Geheimdienst National Security Agency (NSA), ist via LSM-Framework in den Kernel 2.6 integriert. Red Hat hat SELinux in Red Hat Enterprise Linux (RHEL) 4 integriert.

Die Software ergänzt die traditionellen Unix-Rechte um drei weitere Schutzmechanismen. Der wichtigste, Type Enforcement (TE, zu deutsch etwa Typzwang), legt fest, ob ein Prozess (Subjekt) auf ein Objekt zugreifen darf. Dazu werden Subjekte und Objekte über ein zusätzliches Attribut (bei Subjekten Domäne, bei Objekten Typ genannt) Klassen zugeordnet. Ein Subjekt darf nur dann auf ein Objekt zugreifen, wenn eine Regel den Zugriff seiner Domäne auf den Typ des Objekts gestattet. Alles, was nicht ausdrücklich erlaubt ist, ist verboten.

Die Allmacht von root bricht das Rollenkonzept. Benutzer befinden sich immer in einer (von mehreren möglichen) Rollen, wobei die Rolle festlegt, auf welche Domänen und Typen ein Benutzer zugreifen darf. Der Superuser beispielsweise darf nur in der Sysadmin-Rolle Systemverwaltungsaufgaben wahrnehmen, der Zugriff etwa auf die Home-Verzeichnisse anderer Benutzer bleibt ihm dennoch verwehrt. In seiner Standard-Rolle -- der eines unprivilegierten Users -- verhindert die rollenbasierte Zugriffskontrolle (Role-based Access Control, kurz RBAC), dass er Änderungen am System vornimmt.

Das dritte Schutzprinzip in SELinux nennt sich Multi-Level Security (MLS). Es befindet sich noch im Experimentierstadium. MLS definiert unterschiedliche Sicherheitsstufen und kommt ursprünglich aus dem militärischen Einsatz. Objekten werden Geheimhaltungsstufen wie vertraulich, streng vertraulich oder geheim zugewiesen, während Subjekte Freigaben für Geheimhaltungsstufen erhalten.

Kritik an SELinux zielt vor allem auf die Komplexität des Systems ab. Bislang fehlt ein komfortables Frontend, um die umfangreichen Regelwerke zu verwalten. RHEL und Fedora Core enthalten zwei vorbereitete Regelwerke. In der strict policy läuft jedes Programm in einer eigenen Domäne. In Fedora Core 4 existieren dazu rund 1300 Domänen und 40.000 Regeln. Zudem gibt es eine Vielzahl von Rollen mit unterschiedlichen Berechtigungen. Die targeted policy mit rund 800 Domänen und 15.000 Regeln beschränkt sich weitgehend auf Type Enforcement und schützt etwa 70 Programme, vor allem exponierte Netzwerkserver.

Sicherheitserweiterungen für Linux

AppArmor

Auch das seit Service Pack 3 im Suse Linux Enterprise Server (SLES) 9 enthaltenene AppArmor, das Novell mit Immunix eingekauft und im Januar dieses Jahres unter der GPL als Open Source freigegeben hat, setzt auf dem LSM-Framework auf. AppArmor arbeitet mit Regelwerken, so genannten Profilen, für Programme -- für eine Reihe gängiger Anwendungen sind sie bereits in der Distribution enthalten. Anders als SELinux erzwingt AppArmor aber nicht gleich eine Umstellung des ganzen Systems, sondern lässt sich nach und nach für einzelne Anwendungen einführen. Novell betont, dass so die Komplexität der Profile sinkt und die Übersichtlichkeit des Sicherheitssystems steigt.

Das Profil einer Anwendung besteht aus einer meist recht übersichtlichen Textdatei, die ihre Rechte beschreibt, beispielsweise auf welchem Netzwerkport sie lauschen darf, auf welche Dateien zugreifen und so weiter. Das Kernelmodul subdomain, das bislang allerdings nicht im Standard-Kernel enthalten ist, setzt die Regeln über die LSM-Hooks durch. Das Profil einer Anwendung besteht aus einer meist recht übersichtlichen Textdatei, die der Anwendung via POSIX-Capabilities die erlaubten Aktionen zuweist und Zugriffsrechte auf Dateien definiert.

POSIX-Capabilities teilen die üblichen root-Privilegien in einzelne Rechte wie "darf Device-Dateien anlegen", "darf Kernel-Module laden" oder "darf chroot aufrufen" auf. Über das Zuweisen einzelner POSIX-Capabilities im Profile kann man Anwendungen die nötigen Rechte geben, um bestimmte Aufgaben zu erledigen, ohne dass sie dafür die kompletten root-Rechte erhalten müssen. Ein Beispiel: Beim Aufbau einer PPTP-Verbindung ist es nötig, eine neue Route zur Routing-Tabelle hinzuzufügen. Hierfür benötigt der Prozess entweder root-Rechte oder die Capability CAP_NET_ADMIN, die es erlaubt, die Routing-Tabelle zu verändern.

grsecurity

Das Projekt grsecurity von Brad Spengler erweitert die Kernel 2.4 und 2.6 ebenfalls um Sicherheitsfunktionen wie Mandatory Access Control und Schutz vor Buffer Overflows, integriert sich dabei allerdings nicht über LSM in das System. Vielmehr besteht grsecurity aus einem ganzen Satz von Patches für den Kernel. Das dürfte ein Grund sein, warum keine der großen Linux-Distributionen dieses System standardmäßig einsetzt. Mit grsecurity lassen sich feingranular die Rechte von Prozessen und Anwendern auf Dateien und ihre Capabilities festlegen. Bei der Konfiguration wird der Anwender durch ein Lern-System unterstützt, das zunächst nur das System beobachtet und daraus auf Wunsch eine Policy erstellt und aktiviert.

Systrace

Das von Niels Provos entwickelte und wie grsecurity nur als Kernelpatch erhältliche Systrace überwacht die Tätigkeiten einzelner Prozesse. Die Software fängt Systemaufrufe wie fork() zum Starten eines neuen Prozesses, open() zum Öffnen einer Datei oder connect() zum Aufbau einer Verbindung über einen Socket ab und gestattet oder verbietet sie abhängig von der geltenden Policy. Das Regelwerk definiert so, was einzelne Anwendungen letztlich dürfen - egal, ob von root oder einem normalen User gestartet. Im Lern-Modus beobachtet Systrace eine Anwendung, um ihr normales Verhalten kennenzulernen und festzustellen, welche Systemaufrufe für das einwandfreie Funktionieren notwendig sind. Im Enforcing-Modus protokolliert und verhindert Systrace dann unbekannte Aufrufe.

LIDS

Das Linux Intrusion Detection System (LIDS) hat trotz des Namens nichts mit Intrusion Detection zu tun. Das 1999 von Huagang Xie gestartete Projekt, ebenfalls nur als Kernelpatch verfügbar, definiert wie Systrace alle erlaubten Systemaufrufe in einem Regelwerk, und wie bei Systrace existiert auch hier ein Lern-Modus. LIDS kann Aktionen aber auch abhängig vom Benutzer erlauben oder verbieten und so dem Benutzer root Restriktionen auferlegen, sodass selbst der allmächtige Super-User nur vordefinierte Aktionen durchführen darf. Das geschieht, indem root die nicht gewünschten POSIX-Capabilities entzogen werden.

Fazit

Mit allen fünf Sicherheitserweiterungen lassen sich die Zugriffsrechte von Prozessen besser regulieren. Allerdings unterscheiden sich die Produkte erheblich im Aufwand bezüglich der Integration, Konfiguration und Wartung. Während es bei RHEL und SLES bereits ausreicht, SELinux oder AppArmor zu aktivieren und die mitgelieferten Regelsätze für Anwendungen zu übernehmen, muss der Administrator bei den anderen Erweiterungen erst einmal der Kernel patchen und Regeln erstellen. Und während sich SELinux und AppArmor mit wenigen Mausklick deaktivieren lassen, ist die Entscheidung für eines der anderen Systeme nicht so leicht wieder rückgängig zu machen.

Aber auch zwischen den LSM-Erweiterungen gibt es erhebliche Unterschiede. So geht SELinux weit über die Prozess-Kontrolle von AppArmor hinaus und führt mit RBAC gleich ein neues Rechtekonzept ein. Zwar ist dafür die gesamte Umstellung des Systems erforderlich, aber der Sicherheitsgewinn fällt höher aus. Allerdings ist die SELinux-Konfiguration deutlich komplexer. Immerhin liefern RHEL und Fedora Core fertige Policys mit.

Aber auch die LSM-basierenden Erweiterungen haben nicht nur Vorteile. Kritiker weisen darauf hin, dass sich Rootkits der LSM-Hooks bemächtigen könnten und so noch besser im System verstecken könnten. Damit es soweit kommen kann, muss der Schutz aber schon an anderer Stelle versagt haben. (odi) (odi)