Security-Plus für Linux Kernel-Erweiterung SELinux sorgt für zusätzliche Sicherheit

Ordnungsmerkmale

erschienen in: <kes> 2005#2, Seite 16

Rubrik: Systeme und ihr Umfeld

Schlagwort: Betriebssystemsicherheit

Zusammenfassung: Security-Enhanced Linux erhält durch Sicherheitsergänzungen im Betriebssystemkern einen erweiterten, feingranularen Zugriffsschutz. Dieser Mandatory Access Control Layer begrenzt im Sinne einer minimalen Rechtevergabe die Auswirkungen von Programmier- und Konfigurationsfehlern sowie "bösartiger" Software und Anwender.

Autor: Von Dirk Kissinger, München

Linux hat in puncto Sicherheit einen guten Ruf: Das Open-Source-Modell sorgt für Vertrauen bei Anwendern und für schnelle Patch-Zyklen. Zunehmend warten Linux-Distributionen mit Zertifizierungen gemäß Common Operating Environment (COE) des US Department of Defense (DOD) oder Evaluierung nach den Common Criteria auf. Nicht zuletzt sichern zahlreiche Funktionen Betriebssystemkern und -umgebung: Das beginnt mit den klassischen Unix-Konzepten wie der strikten Trennung von Prozessräumen, dem Standard-Rechtesystem über Dateiattribute und geht über POSIX ACLs (Access Control Lists) hin zu ergänzenden Maßnahmen verschiedener Linux-Distributionen, etwa gegen Buffer Overflows.

Beispielsweise hat schon in Red Hat Enterprise Linux 3 eine spezielle Stack-Protection Code-Ausführung in kritischen Speicherbereichen unterbunden. Durch ein permanent wechselndes Speicher-Layout mit dynamischen Adressen bleiben für Hacker die realen Adressstrukturen im Dunkeln – und damit auch mögliche Andockpunkte für Buffer-Overflow-Attacken. Weitere Schutzfunktionen gegen Overflow-Angriffe werden mit der nächsten Generation der GNU-Compiler-Collection-Familie (GCC) in die Standard-Entwicklungsumgebung von Linux Einzug halten.

Dennoch bleiben Programmier- und Konfigurationsfehler auch für Linux ein hohes Risiko. Die traditionelle Methode, dem System die Klassifizierung in einfache Nutzer- oder komplette Root-Rechte zu überlassen, ist angesichts solcher Gefahren kein hinreichender Schutz. Ebenso wenig schützt ein noch so schnelles Bug-Fixing oder Reagieren auf Sicherheitslücken vor Konfigurationsfehlern oder böswilligen Benutzern. Derartigen Risiken und ihren Folgen kann man nur durch ein besser abgesichertes Betriebssystem wirkungsvoll begegnen.

Extrasicherheit im Kern

Ein solcher Ansatz ist das Projekt Security-Enhanced Linux (kurz: SELinux), das die US-amerikanische National Security Agency (NSA) bereits vor einigen Jahren ins Leben gerufen hat [1]. Zunächst arbeiteten neben der NSA die Network Associates Laboratories (NAI Labs), die MITRE Corporation und die Secure Computing Corporation (SCC) an SELinux; über die Zeit haben etliche weitere Personen und Organisationen sowie die Linux-Community zu dem Projekt beigetragen [2]. Red Hat hat beispielsweise etliche Policy-Files und -Patches entwickelt, SELinux im Rahmen des Community-Projekts Fedora [3] ausführlich getestet und mittlerweile in sein Enterprise Linux 4 integriert.

SELinux umfasst verschiedene Erweiterungen zum Linux-Kernel, die eine starke und flexible Mandatory-Access-Control-Architektur in das Betriebssystem einbringen. Dies begrenzt die Folgen von umgangenen oder ausgehebelten Sicherheitsmechanismen genutzter Applikationen und beschränkt mögliche Schäden durch fehlerhafte Anwendungen und Malware.

Im Mandatory Access Control Layer regelt eine zentrale Policy detailliert, welche Zugriffsrechte einzelnen Prozessen eingeräumt werden sollen. Zudem wird durch SELinux das Betriebssystem in verschiedene Security-Kontexte unterteilt. Die Sicherheitserweiterung setzt direkt im Kernel an und überwacht Systemaufrufe unterhalb des klassischen User/Group-Modells, wodurch die originären Sicherheitsmechanismen unberührt bleiben. Parallel treten die Policies in Kraft: Sie regeln, welche Benutzer welche Applikationen in welchem Sicherheitskontext nutzen dürfen.

Kompatibilitätsfragen

SELinux ist für die Anwendungen transparent; bestehende Applikationen (auch Binaries) laufen in der Regel ohne Anpassungen. Für "sicherheitsbewusste" Software stehen jedoch erweiterte Kernel-Datenstrukturen mit neuen Security-Attributen und zusätzliche Systemaufrufe zur Verfügung, um erweiterte Sicherheitsfunktionen zu nutzen. Hierbei werden jedoch weder Standard-Strukturen noch bestehende Systemaufrufe modifiziert, sodass jegliche Standard-Anwendung unverändert abläuft – sofern sie aufgrund der Policy gestartet wird.

Bezüglich anderer Kernel-Module bestand ursprünglich nur so genannte Source-Code-Kompatibilität, sodass derartige Module mit den erweiterten Kernel-Header-Dateien neu kompiliert werden mussten. Seit LSM und SELinux jedoch in den 2.6-Standard-Kern integriert wurden, besteht im Prinzip auch Binary-Kompatibilität zu bestehenden Kernel-Modulen; je nach deren Programmierung kann es allerdings zu Problemen kommen, wenn beispielsweise Standardaufrufe umgangen werden. In solchen Fällen können für ein sauberes Arbeiten Modifikationen unumgänglich sein. Auch einige wenige systemnahe Programme wie Backup-Tools können weitergehende Anpassungen erfordern. Darüber hinaus können zusätzliche Anpassungen notwendig werden, wenn in der Praxis durch die Minimalrechte-Strategie zutage tritt, dass einzelne Programme mehr Rechte anfordern als notwendig. Dann sollte man durch Änderungen an diesen Rechteanforderungen, nicht an den Policies, gegensteuern.

Für die typischen Linux-Anwendungen stehen schon in der Standard-Policy Regeln bereit. Nur in Einzelfällen müssen Policies, welche die minimalen Rechte der Anwendungen festlegen, selbst geschrieben werden. Bei dieser Arbeit können Tools helfen, die die Zugriffe protokollieren.

SELinux en detail

Die Stichworte hier sind Type Enforcement, Role Based Access Control (RBAC) und Identity Management. SELinux kombiniert Elemente dieser Konzepte, um Sicherheit durchzusetzen. Durch Type Enforcement (TE) erhält jedes Objekt im System einen Security-Typ, egal ob es sich dabei um eine Datei im File-System, einen Netzwerkanschluss, ein Device oder einen Prozess handelt. Bei Prozessen spricht man auch von Security Domains, um sie als aktiven Teil des Systems von den Objekten abzugrenzen, auf denen sie operieren. Zusätzlich sind alle Objekte in Klassen unterteilt: File, Directory, Process und so weiter. Ihre "Identität" – sie entspricht einer System-Identity oder bei realen Benutzern dem Unix-User-Account – bestimmt, welche Rollen zugänglich sind.

Über Rollen wird gesteuert, welche Security Domains erreichbar sein sollen; eine Rolle hält für eine Benutzergruppe fest, welche Sicherheitskontexte zugänglich sein sollen. Die Policy bestimmt dann letztlich im Detail, welche Operationen aus welcher Domain heraus auf welche Objekte (abhängig von Security-Typ und Objektklasse) möglich sein sollen. Die Default-Einstellung lautet dabei zur Sicherheit des Unternehmens "deny".

Jeder Prozess im SELinux-System läuft innerhalb einer Domäne ab. Diese wird vom aufrufenden Prozess geerbt, im Rahmen der über die Rolle eingeräumten Möglichkeiten gewählt oder über die innerhalb der Policy definierten so genannten Transition-Rules automatisch zugewiesen. In der Regel kommt das dritte Verfahren zum Einsatz – ausschlaggebend für die Wahl der Methode ist, aus welchem Kontext heraus ein bestimmtes Programm ausgeführt wird.

Initialisiert wird SELinux zur Boot-Zeit durch den Init-Prozess, der vom Kernel mit der Prozess-ID 0 als erstes gestartet wird und den weiteren Boot-Vorgang kontrolliert. Anschließend steuern die Regeln, welche eindeutigen Datei-Pfade, auf welche Dienste und Prozesse ihre definierten Rechte erhalten. Ein Beispiel: Wenn Init das RC-Skript aufruft, das für den Start weiterer Dienste zuständig ist, wechselt es dazu von seiner Domain init_t in die entsprechende Security Domain initrc_t. Wenn RC den Apache-Server startet, dessen Binary den Security-Typ httpd_exec_t hat, so wird die Transition-Rule domain_auto_trans(initrc_t,httpd_exec_t,httpd_t) angewendet.

Grundsätzlich gilt: Die Ausgangs-Domäne und der Typ des ausgeführten Binary bestimmen die Domäne, unter der der neue Prozess ausgeführt wird. Dies heißt auch, dass ein und dasselbe Programm in unterschiedlichen Domains ausgeführt wird, mit vollkommen unterschiedlichen Rechten, je nachdem, "wer" es wann startet. Um im Beispiel zu bleiben: Die Apache-Domain httpd_t hat selbst relativ geringe Privilegien. Das vollständige Security Label eines so vom System gestarteten Webservers (httpd) wäre system_u:system_r:httpd_t, Systemidentität und -rolle werden also weiterverfolgt.

Würde stattdessen ein CGI-Binary aufgerufen, so käme bereits in der Standard-Policy eine entsprechende Regel zur Anwendung, die eine bestimmte Domäne setzt; Aus diesem Kontext heraus ist es nicht möglich, klassische Systemadministrator-Rechte zu erhalten. Ein Hacker, der beispielsweise über einen Remote-Exploit in den Apache eindringt und es sogar schafft, Root-Rechte zu erhalten, wäre dennoch in der Domain des CGI-Bin gefangen. Diese Domäne räumt nicht einmal das Recht ein, statische Webseiten zu verändern, geschweige denn, irgendwelche Rechte-Eskalationen durchzuführen. Die Folge: Nicht einmal ein klassisches "Defacement" (unberechtigte Eingriffe in einen Internet-Auftritt) wäre hier möglich.

Ein weiteres Beispiel für die Sicherheitsfunktion von SELinux liefert ein E-Mail-Programm: Ohne SELinux hat der E-Mail-Client alle Rechte des Anwenders, der es startet, beispielsweise auch vollen Zugriff auf seine Krypto-Schlüssel auf der Festplatte, etwa GPG-Keys. SELinux unterbindet einen solchen Zugriff: Das E-Mail-Programm darf lediglich das GnuPG-Binary ausführen, das auch selbst keine Manipulationen an den Schlüsseldateien durchführen kann, sofern es aus der Security-Domain des E-Mail-Programmes heraus aufgerufen wird. Auch dies ist Teil der existierenden Standard-Policy.

Fazit

Einen gewissen Aufwand zieht die Definition des SELinux-Regelwerks natürlich nach sich. Die Komplexität der Policy-Definitionen entspricht in etwa einer umfangreichen Firewall-Topologie eines größeren Netzwerks, jedoch mit dem Vorteil, dass die meisten Programme stets die gleichen Rechte benötigen und daher Standard-Regeln greifen. Offerten wie Targeted Policy ermöglichen es daher, ohne große Arbeit die wichtigsten Netzwerkdienste wie Apache, Nameserver oder SQL über das Regelwerk abzusichern: In diesem Fall genügt die Eingabe weniger, variabler Konfigurationsparameter. Für eine weitergehende Absicherung sind jedoch Anpassungen an die lokalen Gegebenheiten erforderlich. Hier kommt das Unternehmen nicht daran vorbei, umfangreiche Modifikationen der mitgelieferten Policies durchzuführen. Der erhebliche Sicherheitszugewinn unter SELinux sollte aber diese Mehrarbeit Wert sein. Immerhin schützt er das Unternehmen nachhaltig vor erheblichen Geschäftsschäden.

Dirk Kissinger (kissinge@redhat.com) ist Partner Marketing Manager EMEA bei Red Hat.

Literatur

[1]
National Security Agency, Security-Enhanced Linux, [externer Link] www.nsa.gov/SELinux/
[2]
SourceForge, SELinux for Distributions, [externer Link] http://SELinux.sourceforge.net
[3]
Fedora Project, SELinux integration into Fedora Core, [externer Link] http://fedora.redhat.com/projects/SELinux/