Sicherheitserweiterungen für Linux

Bei einem Einbruch auf einen Server bietet das traditionelle Unix-Rechtemodell nicht genügend Möglichkeiten, um den Schaden zu begrenzen. Neben dem von Red Hat bervorzugten SELinux und AppArmor von Novell existieren weitere Ansätze.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 9 Min.
Von
  • Thorsten Scherf
  • Dr. Oliver Diedrich
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, 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.