Rollenspiele

Um die Tragweite von EinbrĂĽchen zu begrenzen, reglementieren spezielle Linux-Sicherheitserweiterungen Zugriffsrechte. Systrace, grsecurity, SELinux und AppArmor verfolgen unterschiedliche Wege, dieses Ziel zu erreichen.

vorlesen Druckansicht
Lesezeit: 8 Min.
Von
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 Linuxkernel 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.

Verschiedene Ansätze wollen Abhilfe schaffen, um auch im Falle eines Einbruchs dem Angreifer die Übernahme des kompletten Servers so schwer wie möglich zu machen. Sie alle legen ein Mandatory-Access-Control-Modell (MAC) zugrunde, in dem vom Benutzer unabhängige Regeln sehr feinkörnig festlegen, was ein Prozess respektive eine Anwendung 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 [1]. Dabei dürfen lediglich vom Kernel erlaubte Operationen verboten, nicht jedoch verbotene Aktionen zugelassen werden: Ein LSM-Modul kann die Sicherheitseinstellungen also nur restriktiver machen.

SELinux, entwickelt von dem amerikanischen Geheimdienst National Security Agency (NSA), ist via LSM-Framework in den Kernel 2.6 integriert [2]. 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.

Mit SELinux Audit kann sich der Administrator ĂĽbersichtlich alle Meldungen des Sicherheits-Subsystems anzeigen lassen

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.

In der aktuellen c't-Ausgabe 04/06 (ab 6.2. am Kiosk) finden Sie einen ausfĂĽhrlichen Artikel zu SELinux.