Administration

Für die Administration eines SE-Linux-Systems stehen diverse Tools zur Verfügung. Beispielsweise zeigt das kleine Tool »getenforce« den aktuellen SE-Linux-Mode an. Mittels »setenforce 0|1« lässt sich der Mode nun natürlich auch verändern, wobei die 0 für den Permissive Mode steht und 1 für den Enforcing Mode. Permissive Mode bedeutet, dass nicht authorisierte Aktionen zwar geloggt, jedoch nicht verboten werden. Das ist beispielsweise zum Entwickeln neuer Policy-Module hilfreich, bringt aber keine zusätzliche Sicherheit. Anders sieht es beim Enforcing-Mode aus, der zusätzlich zu den Logeinträgen die nicht erlaubten Aktionen. Was erlaubt ist und was nicht, entscheidet der Security-Server anhand der Policy-Einträge. Soll der Mode dauerhaft verändern werden, so ist hierfür ein Eintrag in der Datei »/etc/selinux/config« notwendig (Listing 2).

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

Das interessanteste Tool in Hinblick auf SELinux ist mit Sicherheit »system-config-selinux« (Abbildung 5). Hiermit lassen sich sowohl ganz grundlegende Einstellungen vornehmen, wie beispielsweise der zu verwendene SE-Linux-Mode, wie auch sehr umfangreichere Arbeiten durchführen, wie beispielsweise das Erstellen von neuen Policy-Modulen. Dazu später noch mehr. Desweiteren lassen sich auch sogenannte Booleans konfigurieren. Booleans sind nichts anderes als Anweisungen mit denen vorbereitete Policy-Regeln aktiviert werden können, ohne das man sich hierfür mit der Makrosprache »m4« (auf dieser Sprache basiert die ganze Policy) auseinanderzusetzen hat. Es gibt eine Vielzahl vordefinierter Booleans, so kann man beispielsweise dem Webserver erlauben auf Daten in den Ordnern der User zuzugreifen (UserDir) oder dem Nameserver gestatten, Änderungen an seiner Zonendatei (DDNS) durchzuführen. Auf der Kommandozeile lassen sich diese Booleans mittels getsebool anzeigen. Der Befehl »getsebool -a | grep httpd« beispielsweise listet alle Booleans für den Apache-Webserver auf (Listing 3).

allow_httpd_anon_write --> off
allow_httpd_dbus_avahi --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> on
httpd_ssi_exec --> off
httpd_tty_comm --> on
httpd_unified --> on
httpd_use_cifs --> off
httpd_use_nfs --> off

Es gibt eine Menge Man-Pages die die Booleans der gängisten Netzwerkdienste beschreiben. Für den Webserver hilft hier folgender Aufruf die Seite für »httpd_selinux« .

Abbildung 5: Über das grafische Konfigurationswerkzeug

Natürlich lassen sich Änderungen an diesen Booleans ebenfalls auf der Kommandozeile durchführen. Das Tool hierfür ist »setsebool« . Folgender Aufruf gestattet dem Webserver das Ausführen von CGI-Skripten:

setsebool -P httpd_enable_cgi 1

Ein weiteres interessantes Kommandozeilen-Tool heißt »sestatus« . Es liefert einen Überblick über die aktuelle SELinux-Konfiguration. So zeigt es, welche Policy gerade aktiv ist, welcher SELinux-Mode aktiv ist, und die Einstellungen der Booleans (Listing 4).

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 21
Policy from config file:        targeted
Policy booleans:
allow_console_login                  off
allow_cvs_read_shadow                off
allow_daemons_dump_core              on
allow_daemons_use_tty                on
allow_execheap                       off
allow_execmem                        on
...

Die Policy

Auf aktuellen Linux-Systemem kommt mittlerweile eine Policy zum Einsatz, die sich stark von älteren Versionen unterscheidet. Hat beispielsweise RHEL 4 noch eine rein monolithische Policy verwendet, so kommt heute ausschließlich eine modulare Variante der Policy zum Einsatz. Das bringt eine Menge Vorteile mich sich. So muss sich ein Policy-Entwickler nun nicht mehr mit den kompletten Policy-Sourcen des ganzen SE-Linux-Systems herumschlagen, es genügt, ein einzelnes Modul für die zu schützende Applikation zu entwickeln und es dem System hinzuzufügen. Die Standard-Policy, die Teil der Fedora-Distribution ist (Targeted Policy), stellt bereits eine ganze Menge Applikationen unter das Schutzschild von SE-Linux. Man spricht hier von den sogenannten Targeted-Programmen (daher auch der Policy-Name). Eine Übersicht aller verfügbaren Policy-Module liefert der Befehl »semodule« (Listing 5).

amavis          1.3.1
amtu            1.1.0
apcupsd         1.1.2
audio_entropy   1.1.0
awstats         1.0.0
bitlbee         1.0.0
calamaris       1.2.0
ccs             1.2.0
cdrecord        1.2.1
certwatch       1.0
cipe            1.3.0
clamav          1.5.1
...

Möchte der Admin ein Modul entfernen und so den SE-Linux-Schutz für dieses Programm aufheben, übergibt er einfach die Option »-r« und den Modul-Namen:

semodule -r amavis

Das hebt den Schutz für die angegebene Applikation dauerhaft auf. Natürlich lässt sich das Modul später auch wieder zum System hinzufügen. Das Policy-RPM speichert alle verfügbaren Standard-Module im Verzeichnis »/usr/share/selinux/targeted« . Möchte der Administrator also beispielsweise das Amavis-Modul erneut laden, ruft er »semodule« wie folgt auf:

semodule -i /usr/share/selinux/targeted/↩
amavis.pp

Dieser Aufruf lädt das Amavis-Modul wieder in den Security-Server des Kernels. Der ist dann dafür verantwortlich, anhand der Regelsätze des Moduls, Aktionen die die Amavis-Software betreffen, zu verbieten oder zuzulassen. Da die Module im Binärformat vorliegen, lassen sich die einzelnen Anweisungen natürlich nicht nachverfolgen. Wer eine genaue Übersicht haben möchte, welche Regeln die einzelnen Module mit sich bringen, kann das SRPM (Source-RPM) der eingesetzten Policy installieren oder einfach das grafische Tool »apol« verwenden. Es ist in der Lage, die binäre Policy-Datei im Klartext darzustellen. Hiermit lässt sich die eingesetzte Policy sehr schön erforschen.

Abbildung 6: Die grafische Anwendung

Wem das zu aufwändig ist oder wer nur eine allgemeine Übersicht über die eingesetzte Policy haben möchte, dem hilft »seinfo« weiter (Listing 6). Hier lässt sich schön erkennen, wie umfangreich das gesamte Regelwerk doch ist. So kommen bei der Standardpolicy bereits mehr als 17 0000 Allow-Regeln zum Einsatz.

Statistics for policy file: /etc/selinux/targeted/policy/policy.21
Policy Version & Type: v.21 (binary, mls)
   Classes:            67    Permissions:       232
   Sensitivities:       1    Categories:       1024
   Types:            2166    Attributes:        185
   Users:               8    Roles:              11
   Booleans:          115    Cond. Expr.:       144
   Allow:          171807    Neverallow:          0
   Auditallow:         28    Dontaudit:      134379
   Type_trans:       3286    Type_change:        88
   Type_member:        14    Role allow:         16
   Role_trans:          3    Range_trans:       158
   Constraints:        59    Validatetrans:       0
   Initial SIDs:       27    Fs_use:             17
   Genfscon:           66    Portcon:           292
   Netifcon:            0    Nodecon:             8

Eine weitere neue Eigenschaft der SE-Linux-Policy unter Fedora 8 ist, dass sie nun auch Eigenschaften der alten Strict-Policy enthält. Genauer gesagt ist es mit Targeted-Policy nun auch möglich, Benutzer-Konten einzuschränken, also auf die Role-based-Access-Control (RBAC) zurückzugreifen. Dan Walsh hat hierfür beispielhaft ein Policy-Modul mit dem Namen »xguest« entwickelt [5]. Hiermit kann der Administrator im Handumdrehen aus einem Gnome-Desktop ein Kiosk-Systemmachen. Der einzige User der sich einloggen darf, ist »xguest« . Auf dem Gnome-Desktop stehen diesem Benutzer nur sehr eingeschränkte Funktionen und eine kleine Auswahl von Programmen zur Verfügung. So ist es beispielsweise nur mit Hilfe des Firefox-Webbrowsers möglich auf das Netzwerk zuzugreifen, jede andere Applikation hat keinen Zugriff auf das Netzwerk.

Auch Modifikationen an den Gnome-Einstellungen selbst (»gconf« ) sind untersagt. Also eine ideale Umgebung für Kiosk-Systeme, wie sie oft an Flughäfen und Lobbys zu finden sind. Das Policy-Modul »xguest« kann natürlich auch als Ausgangspunkt für eigene Entwicklung dienen. Beispielsweise könnte man die bestehenden Regelsätze um weitere Anweisungen erweitern, sodass auch auch ein Zugriff via SSH möglich ist.