© photocase.com

Mit Security Enhanced Linux kennt der Linux-Kernel ein MAC-System zur Zugriffskontrolle. Die überarbeitete Version in Fedora Core 5 soll den Einsatz und die Administration vereinfachen und neue Zugriffskontrollmodelle bereitstellen.

SE Linux entstand unter der Leitung des US-amerikanischen Geheimdienstes NSA (National Security Agency) und implementiert ein MAC-System (Mandatory Access Control) basierend auf RBAC (Role-based Access Control), TE (Type Enforcement) und MLS (Multi-Level Security). Aber SE Linux [1] protzt nicht nur mit Abkürzungen (SE steht für Security Enhanced), es erweitert die Sicherheitsfunktionen eines Linux-Systems erheblich. Konventionelle Linuxe arbeiten nur mit einem DAC-Modell (Discretionary Access Control).

Entscheidungsgrundlage

DAC fällt die Entscheidung, ob ein Benutzer auf eine Ressource (etwa eine Datei) zugreifen darf, nur anhand seiner Identität. So ist es möglich, dass eine Applikation wie Adobe Reader nicht nur PDF-Dateien liest, sondern alle Dokumente ihres Benutzers verändert. Das ist besonders kritisch, wenn es sich bei dem Benutzer um Root handelt.

Von der grobschlächtigen Einteilung profitieren Angreifer. Ruft Root den Adobe Reader auf, um ein PDF aus dunklen Quellen zu öffnen, dann kann der Angreifer beim Exploit einer Sicherheitslücke eine Root-Shell aufrufen oder »/etc/passwd« modifizieren. Für seine regulären Aufgaben braucht der Reader keines dieser Privilegien.

MAC mit Regelwerk

Ein MAC-System verhindert im Gegensatz zum DAC solche Zugriffe anhand eines Regelwerks. MAC-Systeme wie LIDS, GR Security, App Armor und SE Linux implementieren eine zusätzliche Policy, die Zugriffe im System regelt und mehr Kriterien als DAC berücksichtigt. Während LIDS, GR Security und App Armor eine Posix-ähnliche Semantik und damit eine leicht verständliche Regelsprache verwenden (siehe Artikel zu App Armor), benutzt SE Linux als zentrales Zugriffsattribut den Security Context.

Dieser Context besteht aus dem SE-Linux-Benutzer (nicht zu verwechseln mit dem Unix-User), seiner Rolle und dem Typ. SE Linux speichert den Security Context für Dateien direkt im Filesystem, derzeit klappt das aber nur mit Ext 3 und XFS. Für Reiser-FS existieren immerhin Patches, JFS wird aber noch nicht unterstützt. Der Aufruf »ls -Z« verrät den Security Context einer Datei: Abbildung 1 zeigt für die Rohdaten zu diesem Artikel »user_u:object_r:paper_t«.

Abbildung 1: SE Linux ordnet allen Dateien und Prozessen einen Security Context zu (hier rot umrahmt). Zusammen mit der Policy leitet sich daraus ab, welche Zugriffe erlaubt sind.

Eine Frage des Typs

Unix-User und -Gruppe lauten auf »spenneb«, während SE Linux den Benutzer als »user_u« führt, seine Rolle heißt »object_r« und der Typ »paper_t«. Die Suffixe der Bezeichnungen deuten jeweils an, um welchen Context-Bestandteil es sich handelt. Auch Prozesse erhalten einen Security Context, den »ps -Z« auflistet (Abbildung 1).

Das wichtigste Kriterium für die Zugriffsentscheidung ist der Typ. Bei einem Prozess heißt der Typ Domäne – dieser sprachliche Kniff soll Subjekt und Objekt besser unterscheiden. Damit nun ein Prozess mit der Domäne »emacs_t« auf eine Datei vom Typ »paper_t« zugreifen darf, braucht er eine entsprechende Richtlinie.

SE Linux verbietet zunächst grundsätzlich jeden Zugriff. Selbst ein Zugriff der Domäne »beispiel_t« auf Dateien vom Type »beispiel_t« ist untersagt. Jede Aktion muss explizit erlaubt sein. Für die Domäne »emacs_t« könnte die Richtlinie folgendermaßen aussehen:

allow emacs_t paper_t:file {create ioctl read getattr lock write append setattr};

Dies erlaubt Prozessen in der Domäne »emacs_t« die in geschweiften Klammern gelisteten Operationen auf Objekte vom Typ »paper_t«. Dass es sich bei den Objekten nur um reguläre Dateien handeln darf, legt die Objektklasse »:file« fest.

Domänenwechsel

Startet ein normaler Benutzer den Texteditor Emacs, verwendet der neue Prozess nicht automatisch die Domäne »emacs_t«. Der Wechsel in diese Domäne muss erlaubt sein und automatisch vonstatten gehen. Dazu definiert eine Regel zunächst für die Binärdatei des Emacs-Texteditors einen so genannten Entrypoint für die neue Domäne.

Die Programmdatei braucht vorab den Typ »emacs_exec_t« (als Label im Dateisystem festgelegt) und SE Linux die folgende Regel:

allow emacs_t emacs_exec_t:file entrypoint;

Damit gestattet SE Linux den ausführbaren Dateien des Typs »emacs_exec_t«, dass sie beim Starten in die Domäne »emacs_t« eintreten. Das genügt aber nicht: SE Linux muss diese Aktion auch dem Aufrufer erlauben. Weil der selbst in einer eigenen Domäne läuft, findet beim Prozessstart ein Domänenwechsel statt. Dazu sind eine Allow- und eine Type-Transition-Regel nötig:

allow { userdomain } emacs_t:process transition;
type_transition { userdomain } emacs_exec_t:process emacs_t;

Die Allow-Regel gestattet allen Prozessen, die einer Domäne aus der Liste »userdomain« angehören, dass sie neue Prozesse in der Domäne »emacs_t« starten. Die darauf folgende Type-Transition-Regel legt fest, dass der aufgerufene Prozess die Domäne »emacs_t« erhält und nicht die des Aufrufers erbt, wenn die Programmdatei vom Typ »emacs_exec_t« ist. Das gilt wiederum aber nur, wenn der Aufrufer einer »userdomain«-Domäne angehört.

Damit SE Linux diese Richtlinien auf einem System umsetzen kann, müssen alle Dateien den korrekten Security Context erhalten. Dieser Vorgang heißt Labeling. Welches File welches Label erhält, steht in den »*.fc«-Dateien (File Context):

/usr/bin/emacs(.*) -- system_u:object_r:emacs_exec_t

Sobald irgendein Prozess auf dem System eine Datei erzeugt, die zu diesem Muster passt, erhält sie von SE Linux den angegebenen Context mit dem Typ »emacs_exec_t«.

Dieses Beispiel verdeutlicht gleichzeitig die außergewöhnliche Granularität, mit der SE Linux arbeitet – und die daraus resultierende Komplexität. Für einen Gelegenheitsadministrator ist das kaum zu überblicken. Eine SE Linux Policy kann durchaus 6 MByte groß sein – dabei enthält sie nur Regeln in Ascii. Seit einiger Zeit versuchen Entwickler diese Komplexität zu reduzieren.

Eine der führenden SE-Linux-Distributionen ist Fedora Core. Sie stellte bis Version 4 zwei Policies zur Verfügung: Strict und Targeted. Während die Strict Policy tatsächlich ein MAC-System für jeden Vorgang auf dem Linux-System implementiert, betrachtet die Targeted Policy nur wenige Dienste, die potenziell kritische Daten verarbeiten. Dies sind in erster Linie Netzwerkdienste. Die restlichen Prozesse unter Fedora Core laufen in einer speziellen Domäne »unconfined_t«, die im Wesentlichen einem System ohne SE Linux entspricht.

Prozessen der Unconfined-Domäne ist beinahe jeder Zugriff erlaubt. Es gelten nur die normalen DAC-Rechte des Linux-Systems. Damit ähnelt SE Linux in diesem Modus dem App-Armor-Ansatz. Dennoch benötigt SE Linux auf Fedora Core 4 auch im Targeted-Modus auf Grund seiner Granularität immer noch eine Policy von 2,5 MByte Ascii.

Verwaltung

Der monolithische Aufbau der Policy erschwert die Verwaltung. Änderungen und Erweiterungen erfordern immer Änderungen am Quelltext der Policy und anschließend eine Übersetzung in die Binärform. Derartige Aktionen bleiben dem Admin vorbehalten. Um seine Arbeit zu vereinfachen, dürfen Policies auch boolesche Variablen erhalten. Deren Wert lässt sich während der Laufzeit ändern, um die gerade geltende Policy zu beeinflussen.

So besitzt die Targeted Policy von Fedora Core 4 insgesamt 95 Variablen. Sie definieren, ob SE Linux die entsprechenden Dienste überwacht oder nicht und wie die Überwachung stattfindet. Die Variable »httpd_can_network_connect« etwa entscheidet, ob der Webserver eigene Netzwerkverbindungen aufbauen darf, etwa zu einem Datenbankserver.

Einzelne Admin-Teilaufgaben auf andere User zu delegieren gelingt damit aber nicht. Ein weiteres Problem ist die Trennung in Strict und Targeted: Es ist kaum möglich, Richtlinien zwischen den beiden Policies auszutauschen.

Reference Policy

Diese Probleme bewegten die Firma Tresys [4] dazu, die SE Linux Reference Policy zu entwickeln [3]. Sie verfolgt mehrere Ziele, vorrangig eine hohe Modularität der Policy. Es soll möglich sein, Module zur Laufzeit zu laden, entladen und auszutauschen. Für die Kommunikation unter den Modulen definiert jedes Modul seine Schnittstelle. Um das Verständnis für die Funktionsweise der Module zu verbessern, enthält jedes eine Schnittstellendokumentation. Aus der Referenz Policy lässt sich sowohl eine Strict Policy als auch eine Targeted Policy erzeugen. Fedora Core 5 hat als erste Distribution die neue Technik eingeführt.

Während die Targeted Policy mit »base.pp« und »enableaudit.pp« nur zwei Module besitzt, besteht die Strict Policy aus 149 binären Modulen. Unter Berücksichtigung ihrer Abhängigkeiten lädt und entlädt der Befehl »semodule« diese Module in das Sicherheitssystem.

Ein typisches Problem beim Einsatz von SE Linux ist, die Policy für ein neues Programm zu ergänzen. Diese Erweiterungen gelingen nun auch mit binären Modulen, ohne den kompletten Regelsatz neu an SE Linux zu übergeben. Ein Modul besteht aus bis zu drei Dateien:

• modul.fc
• modul.te
• modul.if

Die FC-Datei enthält die File-Kontexte. Sie definieren, wie SE Linux die einzelnen Dateien labeln soll. Die TE-Datei enthält wie bisher die Type-Enforcement-Regeln. Die IF-Datei ist neu und enthält die Definition der Modulschnittstelle und ihre Dokumentation. Obwohl Administratoren diese Dateien auch komplett von Hand erstellen können, gibt ihnen in Fedora Core 5 das Skript »policygentool« Unterstützung.

Policy-Modul automatisch erzeugen

Das Policygentool erwartet beim Aufruf einen Namen für das zu erzeugende Modul und den Pfad des Programms, für das dieses Modul gilt. Es stellt anschließend dem Administrator einige Fragen und erzeugt entsprechende Konfigurationsdateien sowie das fertige Modul. Wer es aus den drei Dateien manuell erzeugen will, übersetzt die TE-Datei mit »checkmodule« und baut mit »semodule_package« die »foo.pp«-Moduldatei und lädt sie dann mit »semodule -i foo.pp«.

Lernmodus

Statt alle Details einer Policy mühsam manuell zusammenzusuchen, bietet es sich an, Regeln aus den protokollierten Audit-Meldungen verbotener Zugriffe zusammenzustellen. Genau dies erledigt der Befehl »audit2allow« (Abbildung 2), er implementiert gewissermaßen einen Lernmodus. Ohne Auditd protokolliert SE Linux wie gewohnt in »/var/log/messages«.

Abbildung 2: Mit »audit2allow« analysiert SE Linux die Audit-Trails nach Vorgängen, die gegen die Policy verstoßen, und erklärt sie zu künftig erlaubten Aktionen.

Das Ergebnis des Lernens sind SE-Linux-Regeln, die genau die bisher verbotenen Zugriffe gestatten. Sinnvollerweise läuft dieser Befehl im Permissive-Modus von SE Linux, bei dem das System Übertretungen der Richtlinien nur protokolliert, sie aber nicht unterbindet.

Die für die Reference Policy angepasste Version dieses Befehls unterstützt auch direkt das Erzeugen von Modulen (in der Abbildung gezeigt). Anschließend lädt und aktiviert der Befehl »semodule -i local.pp« das neue Modul. Manuelle Änderungen an der erzeugten TE-Datei sind möglich und sinnvoll, mindestens ein kritischer Blick empfiehlt sich immer.

Bisher kann nur der Systemadministrator selbst die SE Linux Policy modifizieren und eine neue laden. Während das bei der alten Technik auf Grund des monolithischen Designs gar nicht anders möglich war, bietet die neue Reference Policy mit ihrem modularen Aufbau grundsätzlich die Möglichkeit, Policy-Moduldateien mit unterschiedlichen Zugriffsattributen zu versehen.

s0:c0=Vertraulich
s0:c1=Entwicklung
s0:c2=HumanResources

chcat -- +Vertraulich /tmp/file.txt

Abbildung 3: Die SE-Linux-IDE Slide erleichtert die Arbeit mit der modularen SE Linux Reference Policy. Slide ist als Plugin für Eclipse implementiert und profitiert damit von dem enormen Funktionsumfang dieser grafischen Entwicklungsumgebung.

MAC für MAC

Früher hatte ein Prozess, der die Fähigkeit besaß, die Policy zu laden, auch die Möglichkeit, die gesamte Policy zu ändern. Die modulare Struktur erlaubt nun einen neuen Ansatz. Hierzu entwickelt Tresys Technology einen SE Linux Policy Server [6]. Dieser soll neben dem genannten Ziel auch zwei weitere verfolgen: neue Objekte unterstützen, die durch Userspace-Applikationen verwaltet werden, bis hin zu Datenbanken und ihren Tabellen. Zusätzlich soll der Policy Server eine bessere Infrastruktur für die zentrale Verwaltung der Policies mehrerer Systeme liefern.

In der ersten Preview-Version ist es bereits möglich, per Policy spezifische Änderungen an der Policy zu erlauben. Die Entwickler haben mit »policycon« ein neues Kommando eingeführt, das einzelne Policy-Module mit einem Security Context versieht. Anschließend kann eine eigene Policy die Modifikation der Policy gestatten. Hierfür ist wieder der »semodule«-Befehl zuständig, der dann mit dem Policy Server im Userspace kommuniziert. Für Produktionssysteme raten die Programmierer noch vom Einsatz des Policy Server ab. Leider ist es aktuell ein bisschen ruhig um seine Entwicklung geworden.

Entwicklung

Es gibt inzwischen eine recht große Benutzer- und Entwicklergemeinde rund um SE Linux, die weit über NSA (Abbildung 4), Tresys und Red Hat hinausgeht. Seit zwei Jahren findet jährlich das SE-Linux-Symposium [7] statt, bei dem im Februar 2006 an drei Tagen 29 Vorträge und fünf Tutorials rund um SE Linux stattfanden. Die Vortragsfolien stehen auf der Homepage des Symposium zum Download bereit.

Abbildung 4: Vor ein paar Jahren noch undenkbar – heute arbeitet die National Security Agency (NSA) aktiv an freier Software. Sie kooperiert bei SE Linux mit einer weltweit verteilten Entwickler-Community.

In der Entwicklung befindet sich beispielsweise die Integration des IPsec-Framework. Damit wird es möglich, SE Linux auch auf den Transport von Daten übers Netzwerk anzuwenden. Diese Arbeiten haben teilweise bereits Einzug in Kernel 2.6.16 gehalten [10].

Keine Unsicherheit

Beim Einsatz von SE Linux befürchten viele Administratoren sich zusätzliche Sicherheitslücken ins System zu holen. Die große und als Ganzes kaum verständliche Policy trägt viel zu dieser Verunsicherung bei. Dennoch lohnt es, sich Gedanken über den Einsatz eines MAC-Systems wie SE Linux zu machen (eine Liste unterstützter Distributionen finde sich auf [2]). Es verbessert auf jeden Fall die Sicherheit des Systems – SE Linux kann einem Prozess keine zusätzlichen Privilegien verpassen, die er ohne MAC nicht hätte. SE Linux entscheidet nicht alleine, ob ein Zugriff erlaubt ist, auch das normale Linux-DAC muss den Zugriff nach allen herkömmlichen Kriterien erlauben.

Bleibt zu hoffen, dass die SE-Linux-Entwickler weiter an der Benutzbarkeit arbeiten. Mit der Modularisierung und dem Policy Server sind die Grundlagen dafür bereits gelegt. (fjl)