Teile und konfiguriere

Im dritten und letzten Teil dieses Tutorials dreht sich alles um die Reference-Policy, die als Tech-Preview schon in Fedora Core 5 (FC5) zum Einsatz kommt und die fester Bestandteil des für Ende des Jahres erwarteten Red Hat Enterprise Linux 5 (RHEL5) sein wird. Dank dieses neuen, modularen Regelwerks und einiger neuer Frontends lässt sich ein SELinux-basiertes System wesentlich leichter als bisher administrieren und an die eigenen Wünsche anpassen. Alle Beispiele in diesem Teil des Tutorials basieren auf einer FC5-Installation und funktionieren nicht unter RHEL4- oder älteren Fedora-Installationen.

In der täglichen Administration zeigt die in den beiden ersten Teilen des Tutorials vorgestellte SELinux-Architektur einige Schwachpunkte. So fehlen Frontends zum Ergänzen von Regeln zur Policy, alle Dateien des Source-Trees sind manuell mit der korrekten Syntax anzupassen. Entwickler, die ihre Anwendungen mit einem SELinux-Regelsatz schützen wollen, müssen den kompletten Source-Tree der Policy installiert haben, um diesen anzupassen beziehungsweise um eigene Regeln erweitern zu können. Ein modularer Ansatz wäre hier wünschenswert, in dem sich Module für einzelne Programme hinzufügen respektive entfernen lassen.

Ein völlig neuer Ansatz

Die aktuelle in FC5 schon eingesetzte SELinux-Architektur erfüllt diese Wünsche. Neben der NSA und Red Hat ist die Firma Tresys intensiv an der Entwicklung von SELinux beteiligt. Sie hat schon vor einiger Zeit ein Regelwerk namens Reference-Policy entworfen. Dies ist keine neue Policy an sich, sondern dient als Basis, um hieraus die Targeted-, Strict- und MLS-Policy generieren zu können. Den bisherigen monolithischen Ansatz des Regelwerks lösen so genannte Policy-Module ab. Es existiert nun eine Art Basis-Modul, das der Distributor mit ausliefert. Es enthält einen Standard-Regelsatz, den der Kernel beim Systemstart lädt. Regeln für eigene Applikationen lassen sich bequem durch das Schreiben von Modulen hinzufügen. Ohne Zugriff auf die Quellen haben zu müssen, kann der Anwender diese Module manuell oder skriptbasiert generieren und anschließend (nach dem Kompilieren) ebenfalls in den Kernel laden. Für die Entwicklung und Administration dieser binären Module steht eine große Auswahl von Tools bereit.

Ein weiterer Vorteil der Reference-Policy gegenüber den bisher verwendeten Regelsätzen (die alle auf der sogenannten Example-Policy basierten) ist die gemeinsame Code-Basis für alle Policy-Arten. So lassen sich aus dem Code der Reference-Policy problemlos die Targeted- und die Strict-Policy bauen. Neu hinzugekommen ist die Multi-Level-Security-(MLS-)Policy. Auch sie baut auf dem gleichen Code auf und arbeitet nach dem Bell-LaPadula-Prinzip [1]. Diese Implementierung der Mandatory-Access-Control unterteilt Objekte sowohl vertikal (Schutzstufe) als auch horizontal (Kategorie). Schutzstufen könnten sein: Streng Geheim, Geheim, Öffentlich und Nicht Klassifiziert. Kategorien, die man Objekten zuweisen könnte, wären beispielsweise: IT-Abteilung, Marketing, Controlling und Sales - hier alles Firmen-Abteilungen, jedoch sind die Kategorien frei wählbar. Subjekte, also Benutzer und Prozesse, lassen sich ebenfalls einer oder mehreren Kategorien zuordnen und erhalten pro Kategorie eine Schutzstufe. Benutzer/Prozesse dürfen nun auf Objekte einer Kategorie zugreifen, der sie zugeordnet sind. Objekte mit einer höheren Schutzstufe darf man schreiben, aber nicht lesen, Informationen aus Dateien von Benutzern mit niedrigerer Schutzstufe hingegen zwar auslesen, aber nicht verändern (siehe Abb. 1). Dies soll verhindern, das eventuell geheime Informationen nach unten weitergegeben werden.

SELinux speichert die notwendigen Informationen zur Abbildung der Kategorie beziehungsweise Schutzstufe wiederum als Teil des Security-Context. Dieser enthält bei der MLS-Policy ein viertes Feld, das man als Security-Level (nicht zu verwechseln mit der allgemeinen Bezeichnung des Security-Context - Security-Label) bezeichnet. Die SELinux-Terminologie unterscheidet den Security-Level von Objekten, MLS spricht hier von Classifications und bezeichnet den Security-Level von Subjekten als Clearances. Also ähnlich wie beim dritten Attribut des Security-Context, der von einem Type beziehungsweise einer Domäne spricht, abhängig davon, ob es sich um ein Objekt oder ein Subjekt handelt.

Die MLS-Policy entstand speziell für die Server-Anwendung in extrem sicherheitskritischen Umgebungen. Eine Common-Criteria EAL4+/LSPPP-Zertifizierung setzt das Bell-LaPadula Prinzip als Implementierung für Datenvertraulichkeit voraus. RHEL5 befindet sich in der Evaluierung für diese Zertifizierung.

Ebenfalls neu: Sowohl Targeted- als auch Strict-Policy sind per Default mit Support für Multi-Category-Security (MCS) übersetzt. MCS ist eine abgeschwächte Form der MLS, die allerdings nur mit Kategorien und nicht auch noch mit Schutzstufen arbeitet. Dahinter steckt die Idee, dass der Nutzer auf einem per se relativ kompliziert aufgebauten MAC-basierten System mehr Möglichkeiten haben soll, die Sicherheit des Systems zu bestimmen. Das widerspricht zunächst der Idee der Mandatory-Access-Control, bei der die Festlegung der Sicherheit zentral erfolgt. Die aktuelle SELinux-Implementierung sieht nun aber vor, dass der Distributor eine Basis-Policy installiert, die der Systemverwalter um eigene Module erweitern kann. Auch lassen sich diverse andere Eigenschaften des Systems über Booleans bestimmen. Über die Kategorien können Benutzer nun zusätzlich die Sicherheit ihrer eigenen Dateien weiter einschränken. Ein Anwender muss nun einer bestimmten Kategorie angehören, um auf eine Datei derselben Kategorie zugreifen zu können. Dies ähnelt dem Prinzip des POSIX-ACLs, allerdings muss bei der Multi-Category-Security erst ein erfolgreicher Type-Enforcement-Check durchlaufen werden, bevor das System überprüft, ob ein Benutzer anhand seiner Kategorie auf das gewünschte Objekt zugreifen darf.

Hier ein Beispiel für eine Datei mit einem gesetzten Kategorie-Attribut:

[root@tiffy ~]# ls -Z /tmp/test
-rw-r--r-- root root user_u:object_r:tmp_t:Marketing  /tmp/test

In FC5 existieren eine Menge neuer Booleans. Unter anderem lassen sich darüber auch Programme aus der Domäne unconfined_t auf merkwürdiges Verhalten bezüglich der Speichernutzung beziehungsweise -verwaltung überwachen. So gestattet beispielsweise das Boolean allow_execstack Programmen ihren Stack ausführbar (exectuable) zu machen. Da noch viele Programme einen ausführbaren Stack erfordern, ist das Boolean per Default aktiviert. Allerdings erzeugt SELinux einen avc:granted-Eintrag im Syslog. Sieht ein Administrator einen solchen, sollte er die Entwickler via Bugzilla auf das fehlerhaft arbeitende Programm aufmerksam machen. Wer auf Nummer sicher gehen will, deaktiviert das Boolean über den bekannten Weg (setsebool -P allow_execstack=0).

In FC5 verarbeitet das Audit-Subsystem die SELinux-Log-Meldungen. Der zugehörige Daemon ist per Default aktiv und protokolliert nach /var/log/audit/audit.log. Mit ausearch steht ein mächtiges Tool zur gezielten Suche nach Log-Einträgen bereit. Sucht man beispielsweise nach Ereignissen, die im Context den Type http_port_t enthalten, so führt der Aufruf mit der Option -o, gefolgt vom gesuchten Type zum Ziel. Listing 1 zeigt ein Beispiel.

[root@tiffy policy]# ausearch -o http_port_t
----
time->Wed Aug  2 00:24:57 2006
type=AVC msg=audit(1154471097.873:507): avc:  denied  { send_msg } for
pid=2854 comm="yum" saddr=192.168.0.99 src=46365 daddr=209.132.177.50 dest=80
netif=eth0 scontext=root:system_r:system_chkpwd_t:s0-s0:c0,c2.c255
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1154471097.873:507): avc:  denied  { name_connect } for
pid=2854 comm="yum" dest=80
scontext=root:system_r:system_chkpwd_t:s0-s0:c0,c2.c255
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
----

Die neue Reference-Policy

Wer unter FC5 die bestehende Policy nach bekannter Methode abändern möchte, dürfte bei einer Suche nach einem selinux-policy-targeted-sources-RPM zunächst etwas ratlos schauen - es existiert so nicht mehr. Das Gleiche gilt für die Strict- beziehungsweise MLS-Policy. Auch im dazugehörigen Binär-RPM sucht man vergebens nach den Quellen der Policy. Selbst die aus den beiden ersten Teilen des Tutorials bekannte Datei policy.18 findet sich in keiner RPM-Datei, stattdessen liegt im Verzeichnis /usr/share/selinux/targeted/ eine Datei base.pp. Bei dieser handelt es sich um die eigentliche binäre Policy, aus der semodule bei der Installation des RPMs die monolithische Policy-Datei policy.20 generiert. Die 20 kennzeichnet hier wieder die Version der verwendeten Policy-Sprache. Das Modul base.pp enthält das Regelwerk für alle Targeted-Daemons. Wer sich einen Überblick verschaffen möchte, wie die entsprechenden Type-Enforcement- und File-Context-Dateien aussehen, der muss sich das Source-RPM selinux-policy..srpm vom Fedora-Server besorgen.

Installiert man es und wendet anschließend ein rpmbuild -bp auf das spec-File an, sieht man unterhalb von /usr/src/redhat/BUILD/ ein Verzeichnis mit den Quellen der refpolicy; unter policy/modules/ finden sich die bekannten Type-Enforcement- und File-Context-Dateien wieder, sortiert in passenden Unterordnern. So liegen Policy-Dateien für Dienste unterhalb von policy/modules/services/, policy/modules/apps enthält Dateien für Systemdienste und policy/modules/apps/ beinhaltet Policies für weitere Applikationen. Neu gegenüber RHEL4 sind die sogenannten Interface-Files (*.if). Hierbei handelt es sich um Makros, die zu einem Modul gehören. Mit diesen können andere Module auf Ressourcen des eigenen Moduls zugreifen. Mehr dazu später im Beispiel.

Will man nun ein neues Policy-Package base.pp generieren, ändert man die Policy entsprechend, erhöht möglichst die Release-Nummer im Spec-File und lässt über Letzteres ein rpmbuild -bb laufen. Nach einiger Zeit liegen in /usr/src/redhat/RPMS/noarch die fertigen Policy-RPM-Pakete vor. Wie erwähnt, dient der Code der refpolicy als Grundlage für alle drei verwendeten Policies (Targeted, Strict, MLS), deshalb befindet sich im genannten Ordner für jede Policy ein Binär-RPM, das sich per rpm -U installieren lässt. An dieser Stelle explizit der Hinweis, dass ein Editieren der Datei base.pp nicht vorgesehen ist, ein Anpassen der Policy sollte durch das Hinzufügen von eigenen Policy-Modulen erfolgen. Die Idee hinter der aktuellen SELinux-Implementierung ist ja gerade, dass das Anpassen der Policy keine Quellen mehr erfordert, sondern der Benutzer stattdessen eigenständige Module generiert, die die bestehende Policy erweitern.

Den vollständigen Artikel finden Sie in der aktuellen Printausgabe von iX 10/06, unter anderem mit Hinweisen zur Ergänzung der Regeln um eigene Policies und einem Ausblick auf die grafischen Frontends.

(avr)