Nicht für alle Systeme reicht das Sicherheitsniveau aus, das Linux von Hause aus bietet. Abhilfe verspricht das »Security Enhanced Linux«, das insbesondere für kleinere Server geeignet ist, die direkt an das Internet angeschlossen sind und Dienste wie Web, E-Mail oder DNS zur Verfügung stellen.

Eine einfache Benutzbarkeit oder Implementierung in komplexen Umgebungen stand bei der Entwicklung von Selinux nie im Fokus.

Im Jahr 2000 hat die NSA in den USA ein Projekt gestartet, um Vorteile und Machbarkeit eines Zugriffskontrollsystems in Linux-Systemen zu demonstrieren, ohne die einzelnen Anwendungen modifizieren zu müssen. Genannt wurde dieses Projekt »Security Enhanced Linux« oder kurz »SELinux«. Ziel war es, die möglichen Aktionen von Prozessen innerhalb des Li-nux-Systems einzugrenzen. Dieses Vorgehen dämmt zum einen das potentielle Zerstörungsausmaß von Malicious-Code – etwa durch Buffer-Overflow Angriffe – ein und sichert zum anderen die Integrität von Daten und den Schutz von Informationen vor falscher Benutzung. Zentrales Augenmerk lag auf einem Rollenkonzept, um neben einer profilgesteuerten Zugriffsregelung auch die allumfassenden Zugriffsrechte des Systemadministrators als Root einzudämmen – er kann bei herkömmlichen Systemen jederzeit alle Sicherheitsmechanismen umgehen oder deaktivieren.

Das Risiko von Unix- und Linux-Systemen besteht daher darin, dass bei einem Exploit versucht wird, Root-Rechte durch das Ausführen von unerwünschtem Code zu erhalten, um danach das System übernehmen zu können. Das Sicherheitsrisiko von Linux-Systemen besteht darin, dass die Berechtigung, mit der ein Programm ausgeführt wird, nur über die Identität des Benutzers definiert wird, nicht aber durch den Zweck des Programms. Wenn also ein fehlerhaftes Programm durch einen Angriff von seiner beabsichtigten Ausführung abweicht und dann Code des Angreifers ausführt, kontrolliert der Angreifer bereits das System. Wenn das Programm mit Superuser-Rechten lief, erhält der Angreifer Zugriff auf das gesamte System.

Nach der erfolgreichen Implementierung durch die NSA wurde das Projekt unter der GPL-Lizenz der Open-Source-Community übergeben, wo sich bis heute eine Reihe von Weiterentwicklungen sowie Steuerungs- und Monitoringtools entwickelt haben. Im Linux-Kernel 2.4 wurde entschieden, dass Security-relevante Teile in eigene Module umgesetzt werden. So entstanden die »Linux Security Modules«, kurz LSM. LSM stellt ein Interface für Security-Module dar, womit unter anderem eine Implementierung von Selinux ohne umfangreiches Patchen des Kernels durchgeführt werden konnte.

Selinux überwacht:

• Die Kontrolle über Raw-Access-Zugriff auf Daten,

• die Integrität des Systemkernels,

• die Integrität der System-Software,

• die Integrität der System-Configuration,

• die Integrität der System-Logs,

• die Zugriffsprivilegien,

• die Verhinderung der Ausführung von Malicious-Code bei privilegierten Prozessen durch geeignete Policies,

• die Administratorrolle,

• den Zugriff von User-Prozessen auf System-Prozesse sowie

• die Einbindung in Free-SWAN-VPN.

Die Überwachung der Konfiguration geschieht durch Policy-basierte Access-Control-Listen. Eine Access-Control-Liste bezieht sich auf ein bestimmtes Objekt, für welches der Zugriff definiert beziehungsweise geregelt werden soll. Es wird daher auch von profilbasierten Policies gesprochen. Das schafft ein flexibles Steuerungsinstrument, das Benutzern und Applikationen definierte Rollen mit definierten Zugriffsrechten zuweist, in deren Kontext sie Aktionen im System ausführen dürfen.

Das sogenannte Mandatory-Access-Control (MAC) basiert auf Type-Enforcement (TE). Dies ist ein Mechanismus, welcher ursprünglich für das »LOCK-System« entwickelt wurde. TE weist alle Ressourcen-Domains beziehungsweise -Typen zu, auf welchen Zugriffsregeln definiert werden (Zugriffsmatrix). Dies wird auch Labeling genannt. Labels werden in den erweiterten Attributen des Filesystems gespeichert, das Filesystem muss daher ausreichend erweiterte Attribute zur Verfügung stellen. Alle zu einer Anwendung gehörenden Dateien werden daher der gleichen Domain zugewiesen und haben anschließend nur Zugriff auf diese.

Unix-Systeme bestehen aus Discretionary-Access-Controls (DAC), in welchen die Besitzer von Objekten, Dateien und Daten deren Zugriffsrechte bestimmen. MAC bestimmt Zugriffsrechte durch Policies und Labels (Domains). Des Weiteren wird festgelegt, wer Policies und Labels vergeben und verändern darf. Die Darstellung als Rollen dient der Abstraktion der Zuweisung von Zugriffsrechten an Benutzer. MAC dient dazu, die Zugriffsmöglichkeiten des Systemadministrators einzuschränken. Rollen können von Benutzern gewechselt werden.

Die NSA hat das System in zwei Architekturen gesplittet: »DTMach« (Distributed-Trusted-Mach-Kernel) und »DTOS« (Distributed-Trusted-Operating-System). DTMach beinhaltet einen Mikrokernel (Mach) mit Sicherheitserweiterungen und Zugriffskontrollmechanismen für das Prozessmanagement, Filesystem und Netzwerk-Protokoll. DTOS beinhaltet das Policy-Modell, welches als Security-Server auf den Mach-Kernel zugreift und die Zugriffskontrolle (MAC) für Systemobjekte und Services spezifiziert.

Ein großer Vorteil dieser Architektur liegt in der strikten Trennung von Policy-Enforcement- (DTMach) und Policy-Decision-Software (DTOS). Dies ermöglicht es, eine große Bandbreite von Security-Policies zu erstellen, ohne jeweils den System-Kernel oder die Applikationen entsprechend verändern zu müssen.

Besondere Eigenschaften der Sicherheitserweiterungen sind:

• Trennung von Security-Enforcement und Policy,

• klar definiertes Policy-Interface,

• Enforcement unabhängig von Policy und Policy-Sprache,

• Unabhängigkeit von spezifischen Security-Formaten und Inhalten,

• Caching von Zugriffsentscheidungen zur Erhöhung der Effizienz,

• Policy-Änderungen im laufenden Betrieb,

• Kontrolle über Prozess-Initiierung, Inheritance und Ausführung,

• Kontrolle über Filesystem, Verzeichnisse, Dateien und offene File-Descriptoren zur Sicherung der Datenintigrität und Schutz der Informationen vor unberichtigtem Zugriff sowie

• Kontrolle über Netzwerkverbindungen (Sockets, Interfaces, Protokoll).

Das DTOS-System wurde anschließend um dynamische Security-Policies erweitert. Diese Architektur wird FLASK genannt.

Um das Policy-Modell effizient im Netzwerkbetrieb umsetzen zu können, erhielten IP-Pakete die sogenannten Security-Identifiers. Hierdurch werden auch Netzwerkverbindungen in einem Security-Kontext ausgeführt, den der Security-Server kontrolliert. Unerlaubte Verbindungen können hierdurch erkannt und unterbunden werden.

Vorteile von Selinux

Das Policy-Modell von Selinux wird auf Benutzer und Services mit Zugriffen auf Files und Devices umgesetzt. Hierdurch kann ein granulares Aktionsprofil erstellt werden, in welchem sich ein Anwender beziehungsweise eine Anwendung bewegen darf. Entscheidend ist die Möglichkeit, Zugriffsrechte auf ein Minimum zu reduzieren. Der Wirkungsraum für Exploits, Malicious-Code oder Datenspionage wird so wirksam eingedämmt. Es wird strikt getrennt zwischen dem Benutzer und den Anwendungsprozessen – und somit den Security-Kontexten.

Eingeloggte Benutzer können ihren Sicherheitslevel selbstständig durch neue Authentisierung (beispielsweise Passwort) verändern, ohne neu einzuloggen (Wechsel der Domain). Applikationen sind binärkompatibel zwischen Linux und Selinux. Selinux ist für Applikationen komplett transparent.

Nachteile von Selinux

Die Flexibilität der Selinux-Architektur schlägt sich in der Komplexität der Konfiguration nieder. Zwar gibt es eine Reihe von Konfigurations- und Monitoringtools – dennoch ist der Einsatz von Selinux erst nach gründlichem Studium möglich. Bei Misskonfiguration kann sehr schnell das gesamte System lahm gelegt werden oder keinerlei Zugriff mehr auf Systemkomponenten möglich sein. Abhilfe schafft in diesem Fall nur das Starten des Systems mit einem Backup-Kernel ohne Selinux-Erweiterung. Dabei ist jedoch Vorsicht geboten, denn alle Zugriffsbeschränkungen, die mit dem Selinux-Kernel definiert worden sind, haben für einen solchen Backup-Kernel keine Bedeutung – es besteht unter Umständen voller Zugriff auf die zu schützenden Informationen – die Integrität und der Schutz von Informationen ist nicht mehr gewährleistet.

Der Enforcement-Teil von Selinux – die Erweiterungen im Systemkernel – bringt Probleme bei Einsatz von Linux-Systemen unter einer System-Maintenance und Support mit sich. Der Support und die Maintenance wird hierdurch eingeschränkt und kann ebenfalls Probleme beim Support von Anwendungen auf Basis von Selinux mit sich bringen. Zertifizierungen von Software-Herstellern basieren in der Regel auf einem definierten Kernel, glibc-Version und Zustand und werden somit gebrochen.

Viele Kernelmodule berücksichtigen heute die Security-Vorgaben (Labels und Domains) von Selinux – aber nicht alle. Für den Kernel und die Kernelmodule hat Selinux Auswirkungen – und ist leider nicht so transparent wie bei Applikationen. Es kann daher zu unvorhersehbarem Verhalten kommen. Dies gilt insbesondere für Hardware-nahe Kernelmodule und Treiber, welche die Zugriffskontrolle von Selinux nicht unterstützen. Dies ist im einzelnen zu überprüfen.

Selinux ist kein sicheres Linux-Betriebssystem. Selinux ist ein wichtiger Schritt, um zu einem solchen System zu kommen. Selinux fokussiert auf Mandatory-Access-Controls. Weitere notwendige Funktionalitäten wie System-Audit und Dokumentation, die zu einem »Trusted«-Linux-System führen, müssen anderweitig hinzugefügt werden. Selinux als Framework genügt nicht den Sicherheitsrichtlinien der Common-Criteria (EAL x+ Zertifizierung).

Die Einbindung von Selinux in ein Backup-Konzept gestaltet sich problematisch, da hierfür eine Rolle mit allumfassenden Zugriffsrechten auf die zu schützenden Daten und Dateien notwendig ist und heute kein Backup-System die Zugriffsprofile für Dateien wiederherstellen kann. Hierfür ist eine Sicherung der erweiterten Attribute und Domainenzuweisung notwendig, um ein vollständiges Restore aus dem Backup durchführen zu können. Sicherheitsbewussten dürfte es zudem wichtig sein, dass genau diese Security-Einstellungen (Policies und Labels) in einem separatem Backup gesichert sind. Selinux unterstützt XFS und ReiserFS nicht, da beide Filesysteme die Security-Attribute von Selinux nicht abbilden können. Für ReiserFS gibt es derzeit nur eine experimentelle Implementierung.

Einsatzszenario

Selinux ist geeignet für den Einsatz auf kleinen Servern mit direktem Anschluss an das Internet, die in Gefahr sind, angegriffen zu werden und einen hohen Level an Sicherheit und Datenintigrität benötigen. Es ist nicht ratsam, Selinux für große Applikation- oder Datenbankserver zu verwenden. Alleine die Komplexität der Konfiguration würde hier den Nutzen übersteigen. Die Komplexität der Konfiguration kann aber auch ohne weiteres den Nutzen bei einer einzigen kleinen Applikation übersteigen. Heute findet sich Selinux meist auf sicheren Web-Servern, insbesondere wenn ein Server mehrere Dienste, wie E-Mail oder DNS, ausführt und diese in unterschiedlichen Domains ausgeführt werden sollen. So kann der Zugriff auf diese Dienste und Daten vom Administrator kontrolliert werden. Gerade im Fall einer Kompromittierung eines Systems kann die Sicherheit der nicht kompromittierten Dienste auf dem gleichen Server gewährleistet werden. Wird auf einem Server lediglich ein Service ausgeführt, so ist der Nutzen gering. Die strikte Trennung von Prozessen und Informationen in eigene Domains durch Selinux ist dann nicht notwendig.

Bei der Betrachtung von Selinux sollte beachtet werden, dass die NSA mit Selinux eine Technologie-Studie durchgeführt hat. Das Ziel, die technischen Ansätze einer MAC zu implementieren und die Nutzbarkeit darzustellen wurde hiermit erreicht. Eine einfache Benutzbarkeit oder Implementierung stand jedoch nie im Fokus.

Stefan Zosel, Senior Solution Specialist, Plattform Linux, Novell