Gut geschützt

Schon der erste Teil des Tutorials behandelte einige Sprach-Elemente der SELinux-Policy, dieser zweite Artikel wird das vertiefen. Er erörtert die einzelnen Policy-Dateien und deren Aufgabe. Am Ende soll er anhand einer neuen Anwendung die bestehende Policy um eigene Regelsätze erweitern helfen. Wie im ersten Teil basieren alle Beispiele auf Red Hats Enterprise Linux 4 (RHEL4), sollten sich aber auf anderen Distributionen mit aktiviertem SELinux nachvollziehen lassen. Wie dort [1] erklärt, seien Benutzer von Fedora Core 5 auf den dritten Teil verwiesen, da es schon die nächste SELinux-Generation verwendet.

Die Arbeit an dem Regelwerk erinnert den einen oder anderen Leser eventuell an das Arbeiten an einem Programm, da auch hier eine Source- und eine Binär-Version existiert. Sobald eine Änderung an den Quellen stattgefunden hat, muss der Systemverwalter mit dem Compiler checkpolicy eine neue Binär-Version erzeugen, die er anschließend per load_policy in den Security-Server des Kernel lädt.

Auf Grund der Komplexität des Regelwerks haben es die Entwickler in unterschiedliche Dateien aufgeteilt, die der Makroprozessor m4 über ein Makefile gesteuert nacheinander zu einer Datei policy.conf zusammensetzt, bevor daraus per checkpolicy die Binär-Version policy.18 entsteht. Dabei expandiert m4 die in den einzelnen Policy-Dateien verwendeten Makros; Abbildung 1 zeigt den Ablauf.

Type-Enforcement und Zugriffsregeln

Daher empfiehlt sich an dieser Stelle zunächst ein genauerer Blick auf das Quellverzeichnis unterhalb von /etc/selinux/targeted/src/policy. Die wohl wichtigsten Dateien, aus denen das Regelwerk entsteht, sind die so genannten Type-Enforcement- und File-Context-Dateien. Jedes innerhalb der SELinux-Targted-Policy in einen Käfig eingesperrte Programm hat unterhalb von domains/program/ eine eigene Type-Enforcement-Datei - üblicherweise mit der Dateiendung .te. Will man ein neues Programm durch SELinux schützen, ist hier eine neue Datei für das Programm anzulegen. Bestehende Dateien lassen sich natürlich auch modifizieren, allerdings würde ein Update des Policy-Source-RPMs die Änderungen wieder überschreiben. Deshalb nimmt man Modifikationen besser über die Datei domains/misc/misc.te vor. Der dazugehörige Ordner ist per Default leer und wird somit auch bei einem Update nicht überschrieben. Type-Enforcement-Dateien definieren die Typen, die das System später an Objekten vergibt, Zugriffsvektoren - also beispielsweise allow-Anweisungen - und Booleans. Listing 1 zeigt ein Beispiel aus der apache.te.

type httpd_config_t, file_type, sysadmfile; 
daemon_domain(httpd, `, privmail, nscd_client_domain') 
bool httpd_enable_homedirs false; 
if (httpd_enable_homedirs) { 
allow { httpd_t httpd_sys_script_t httpd_suexec_t } 
user_home_dir_t:dir { 
getattr search }; 
}

Als erstes definiert dieses einen File-Type httpd_config_t. Diesen verwenden die File-Context-Dateien später dazu, die Konfigurationsdateien des Webservers mit einem Label zu versehen. Eine Datei lässt sich nur dann mit einem Type „labeln“, wenn dieser vorher definiert wurde. Hinter dem Namen des Type kann man Attribute angeben - dazu später mehr. In der zweiten Zeile steht der Aufruf des Makros dae mon_domain mit dem Argument httpd. Auch hier lassen sich wieder Attribute übergeben. Zur Definition des Makros später mehr. Die Zeilen drei bis sieben definieren ein Boolean httpd_enable_homedirs mit Default-Wert false (bool httpd_enable_homedirs false;). setse bool httpd_enable_homedirs=1 aktiviert die allow-Anweisung. Sie gestattet Programmen aus den Domänen httpd_t, httpd_sys_script_t und httpd_suexec_t, Zugriff auf Ordner mit dem Type user_home_dir_t. Die Targeted-Policy versieht das Verzeichnis ~/pub lic_html mit diesem Label. Es gestattet durch das Aktivieren also den Zugang zu benutzerspezifischen Webseiten.

Wie im ersten Teil beschrieben, stehen die Access-Vektoren allow, audit allow und dontaudit zur Verfügung. Hier je ein Beispiel für deren Anwendung:

auditallow unconfined_t security_t:security { load_ policy setenforce setbool };

Üblicherweise protokolliert SELinux lediglich unerlaubte Aktionen. Manchmal ist es aber auch sinnvoll, erlaubte Aktionen im Log festzuhalten. Dazu dient auditallow, es protokolliert durch allow-Anweisungen gestattete Aktionen. Im obigen Beispiel landen also das Laden einer neuen Policy, der Wechsel des SELinux-Modus (permissive oder enforcing) und das Setzen eines Booleans im Syslog - so eine passende allow-Anweisung existiert.

dontaudit verhält sich genau andersrum: Dank dieses Access-Vektors protokolliert das System verbotene Aktionen nicht. Das kann das Überlaufen der Logs durch häufig auftretende, unautorisierte Aktionen vermeiden. Beispielsweise verhindert

dontaudit httpd_t console_device_t:chr_file { ioctl read getattr lock write append };

das Logging jedes Webserver-Zugriffs auf die Konsole.

Beim Schreiben von Type-Enforcement-Regeln lassen sich einige spezielle Notationen verwenden.

allow httpd_t self:process ~{ ptrace setexec setfscreate setrlimit };

self als Target bezieht sich hier auf Prozesse, die ebenfalls in der Domäne httpd laufen. ~ gestattet kompletten Zugriff mit Ausnahme der aufgeführten Rechte.

allow unconfined_t security_t:security *;

Das Sternchen bezieht sich auf alle für diese Objektklasse (security) zur Verfügung stehenden Berechtigungen.

allow {domain -httpd_t} etc_t:file r_file_perms;

gestattet allen in einer Domäne mit dem Attribut domain laufenden Prozessen den Zugriff auf Objekte vom Type etc_t. -httpd_t generiert hier für die Webserver-Domäne eine Ausnahme.

In der Printausgabe lesen Sie Details zum Makroeinsatz und wie sich mit Attributen und Rollen die Policy-Einstellungen anpassen oder erweitern und das gewünschte Sicherheitsnineau erreichen lassen.

Literatur

[1] Thorsten Scherf; SELinux-Tutorial I; Gut bewacht; Mandatory Access Control für Linux-Systeme; iX 8/2006, S. 134

[2] Thorsten Scherf; SELinux; Sicherheit im Linux-Kernel; ISBN 3-937514-28-7, Open Source Press, München, circa Dezember 2006

(avr)