Policy-Suche

Ist ein Benutzer in dieser Map-Datei nicht explizit aufgeführt, findet der Zugriff lediglich über die Domäne »user_webapp_t« statt, ohne gesetzte MCS-Kategorie. Das Tool »sesearch« verrät, auf welche Objekte ein Zugriff aus der Domäne »user_webapp_t« gestattet ist ( Listing 5 ). Diese neuen Regeln für die SELinux-Policy stammen aus dem Policy-Paket »mod_SELinux.pp« . Das Paket wird nach der Installation von Mod-SELinux automatisch geladen, wie ein Aufruf von »semodule« bestätigt:

# semodule -l | grep mod_SELinux
mod_SELinux 2.2

Natürlich kann der Administrator der Policy eigene Regeln hinzufügen. Hierfür muss er dann aber ein eigenes Policy-Paket entwickeln. Wie das geht, verrät ein anderer Artikel des Autors [4] . Alle nicht authentifizierten Zugriffe auf den Webserver laufen, wie in der Map-Datei festgelegt, in der SELinux-Domäne »anon_webapp_t« .

Nur mit PostgreSQL

In größeren Umgebungen wird der Admin die Benutzer aber in einer Datenbank ablegen wollen und die Authentifizierung hierüber abwickeln, zumal beim Einsatz einer Webapplikation meist ein Datenbanksystem vorhanden ist. Im folgenden Beispiel kommt dafür das bereits angesprochene SE PostgreSQL zum Einsatz. Das hat den Vorteil, dass der Administrator alle Objekte der Datenbank mit einem Security Context verknüpfen kann, was bei anderen RDBMS-Systemen nicht möglich ist.

Die Installation gelingt bei den meisten Linux-Distributionen wieder aus dem Standard-Software-Repository heraus. Alternativ finden sich auf der Webseite des Projekts [2] die Sourcen. Auf einem Fedora-System installiert der folgende Yum-Aufruf die Datenbank:

yum install sepostgresql

Im Anschluss muss der Administrator die Datenbank initialisieren und neu starten, dies übernehmen die folgenden beiden Befehle:

/etc/init.d/sepostgresql initdb
/etc/init.d/sepostgresql start

Für den administrativen Zugriff auf die Datenbank existiert ein Standardbenutzer »sepgsql« . Über ihn kann der Administrator die erste Datenbank erzeugen und dann Benutzerobjekte darin anlegen ( Listing 6 ).

In der Konfigurationsdatei von »mod_SELinux.conf« kann man nun zur Authentifizierung der Benutzer einer Webapplikation auf diese Objekte zurückgreifen. Der passende Security Context ist zu jedem Benutzerobjekt bereits in der Datenbank hinterlegt, somit ist kein Mapping mehr durchzuführen.

Die notwendigen Direktiven für die Konfiguration von »mod_SELinux« zeigt Listing 7 . Hier sind zuerst die passenden Apache-Module zum Zugriff auf die Datenbank zu laden. Die nächsten beiden Parameter legen den gewünschten Treibernamen und die Anmeldeparameter für den Zugriff auf PostgreSQL fest. Im Anschluss erfolgt die Authentifizierung der Benutzer. Diese wandern dann über die Variable »AUTHENTICATE_UDOMAIN« an Mod-SELinux. Klappt die Anmeldung eines Benutzers nicht, dient als Fallback-Lösung wieder der Security Context »anon_webapp_t« .