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).

Listing 2

/etc/selinux/config

 

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).

Listing 3

getsebool -a | grep httpd

 

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).

Listing 4

sestatus -b

 

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).

Listing 5

semodule -l

 

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.

Listing 6

seinfo

 

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.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2022