Thread-Ebene

Dank Mod-SELinux ist es nun also möglich, einzelne Webserver-Prozesse (genauer Webserver-Threads) mit einem jeweils individuellen Security Context zu starten. Über SELinux-Regeln definiert der Administrator dann, welche Objekte auf diese einzelnen Threads zugreifen dürfen. Wer sich die Dokumentation etwas genauer anschaut, stellt schnell fest, dass das Einsatzgebiet bei den hier vorgeführten Beispielen nicht aufhört. So kann der Administrator mittels Mod-SELinux beispielsweise auch einzelne virtuelle Apache-Hosts mit einem jeweils eigenen Security Context starten oder in Abhängigkeit der IP-Adresse eines zugreifenden Hosts den Context setzen.

SE PostgreSQL mit MAC-Schutz

Die folgenden Abschnitte führen die SELinux-Konfiguration eines relationalen Datenbank-Verwaltungssystems am Beispiel von SE PostgreSQL vor. Dabei handelt es sich um eine Erweiterung des bekannten PostgreSQL-Datenbanksystems. Die Erweiterung ermöglicht es, einzelne Objekte mit einem SELinux Security Context zu versehen und beim Zugriff auf diese Objekte den Security-Server im Kernel zu fragen, welche Rechte der Kontext des zugreifenden Sockets in Bezug auf das angefragte Objekt besitzt.

Listing 8 zeigt den schematischen Ablauf. Zuerst meldet der Administrator sich erneut mit einem administrativen Konto am RDBMS an und erzeugt eine neue Datenbank, in diesem Fall »footballdb« . Anschließend verbindet er sich über die Psql-Clientanwendung mit der Datenbank und erzeugt eine neue Tabelle, hier »clubs« . Diese bekommt einen einzelnen Datensatz zugewiesen.

Das erste Select-Statement gibt den Datensatz aus. Hierbei zeigt sich, dass dieser bereits über einen Security Context verfügt. Der Typ für diesen Default Security Context lautet für Zugriffe aus der »unconfined_t« -Domäne jeweils »sepgsql_table_t« . Wer den Kontext ändern will, erreicht dies mit einem einfachen Update-Statement. Der letzte Select-Aufruf verifiziert, dass der Datensatz nun über einen neuen Typ im Security Context verfügt.

Natürlich lässt sich ein Kontext nicht nur auf eine Datenbankzeile anwenden, sondern auch auf einzelne Spalten. Listing 9 zeigt ein Beispiel. Hierbei handelt es sich um eine Tabelle, die Mitarbeiterdaten enthält. Für diese Spalte soll der Security Context »sepgsql_secret_table_t« zum Zuge kommen. Auf diesen Typ darf eine reguläre SELinux-User-Domäne nicht zugreifen. Dies bestätigten die letzten beiden Select-Statements. Der Befehl »SELECT sepgsql_getcon();« zeigt den Security Context des zugreifenden Sockets an, in diesem Fall handelt es sich um die User-Domäne »user_t« .