SELinux in der Praxis

Innerhalb meiner Firma hat es sich irgendwie eingebürgert, neue Entwicklungen immer zuerst an Familienmitgliedern auszuprobieren, bevor diese auf die Allgemeinheit losgelassen werden. Bei einem Kollegen aus den USA ist es die eigene Ehefrau, bei mir meistens der Sohn, manchmal ist aber auch meine Frau das Versuchskaninchen. Diese besitzt allerdings auch einen Mac, sodass neue Policies primär auf dem Rechner meines Sohnes getestet werden. Sitzt dieser an seinem Fedora-System, so sind zumeist nur drei Applikationen geöffnet, der Webbrowser, sein Lieblingsspiel und ein IRC-Client, über den er sich mit Freunden über das Spiel austauscht – das behauptet er zumindest.

Auf dem Fedora-System läuft die SE Linux-Targeted-Policy, und sein Account wird auf den SE-Linux-Benutzer »user_u« gemappt. Damit hat er Zugriff auf sämtliche Netzwerkressourcen, »setuid« und »setgid« sind jedoch außen vor. Logge ich mich auf dem System ein, wird mein Konto auf »staff_u« gemappt, damit erhalte ich dann ebenfalls auch Zugriff auf »sudo« und kann so den Rechner verwalten.

Dieses Setup läuft nun schon eine ganze Zeit auf seinem Rechner, und es gab bisher keine großen Probleme. Läuft ein Programm mal nicht so wie es soll, dann hilft der »setroubleshoot« -Daemon dabei, das Problem einzukreisen und zu beheben. Er hinterlässt eine Meldung in der Logdatei »/var/log/messages« und gibt dabei genaue Anweisungen, wie sich das Problem lösen lässt. Auf Desktop-Systemen gibt außerdem ein Applet Auskunft darüber, wenn ein Zugriff durch SE Linux blockiert wurde.

Schutz vor Malware

Auch im Wohnzimmer steht ein Familien-Notebook, auf dem sich vor allem meine Frau und mein Sohn anmelden und auf dem meistens ein Webbrowser und ein IRC-Client laufen. Sicher ist es sinnvoll, die Accounts auf dem Familien-Rechner noch weiter abzusichern, dachte ich mir dann eines Tages, und stellte die beiden User-Accounts von »user_u« auf »xguest_u« um. Nun gestattet dieser SELinux-User-Account den Zugriff auf das Netzwerk jedoch nur über den Firefox-Webbrowser, alle anderen Netzwerkzugriffe werden unterbunden.

Somit wird also sämtlichem Ungeziefer, das eventuell aus den Weiten des World Wide Web den Weg auf den Familen-Rechner gefunden hat, der Zugriff auf das Netzwerk verboten. Es ist noch nicht einmal möglich, dieses Ungeziefer aus dem Download-Ordner zu starten (oder sich selbst starten zu lassen). Dieses Verhalten lässt sich jedoch über ein SE Linux ändern. Schließlich soll auf dem Rechner nicht nur gespielt, sondern von Zeit zu Zeit auch mal gearbeitet werden. Über eine Boolean-Variable lässt sich das jeweils gewünschte Verhalten zur Laufzeit einstellen:

# getsebool allow_xguest_exec_content
allow_xguest_exec_content --> off

Das Mapping auf den SE-Linux-Benutzer »xguest_u« habe ich zuvor mittels »semanage« eingestellt:

# semanage login -m -s xguest_u linus
# semanage login -l | grep linus
linus xguest_u s0

Damit kann sich mein Sohn wie zuvor anmelden, bekommt nun aber den SE-Linux-Benutzer »xguest« auf seinen eigenen Account gemappt:

$ id -Z
xguest_u:xguest_r:xguest_t:s0

Ein Zugriff auf das Netzwerk ist nun nur über den HTTP-Port 80 möglich, jeder andere Zugriff wird unterbunden:

$ ping 8.8.4.4
ping: icmp open socket: Permission denied
$ nc -v aspmx.l.google.com 25
nc: connect to aspmx.l.google.com port 25 (tcp) failed: Permission denied
$ nc -v www.google.com 80
Connection to www.google.com 80 port [tcp/http] succeeded

Soweit so gut, allerdings klappt nun der Zugriff auf den IRC-Server natürlich auch nicht mehr. Versuche ich den IRC-Client zu starten, erscheint folgende Fehlermeldung im Log:

Aug 16 15:50:34 tscherf setroubleshoot: SELinux is preventing /usr/bin/xchat
from name_connect access on the tcp_socket .For complete SELinux messages run sealert -l482a1457-4fdc-4d8c-91d0-d5ddf4b23891

Um Diskussionen von Anfang an aus dem Weg zu gehen, wollte ich dieses Manko natürlich beheben und ein entsprechendes SE-Linux-Policy-Modul entwickeln, das den Zugriff auf einen IRC-Server ermöglicht, auch wenn der angemeldete Benutzer auf den SE-Linux-Account »xguest_u« gemappt ist.

Eigene Regel

Rufe ich also wieder »sealert« auf, teilt das Tool mir mit, dass der Zugriff auf den IRC-Port 6667 unterbunden ist. Der Aufruf von »audit2allow« bestätigt dies und schlägt vor, das Standardregelwerk um folgenden Eintrag zu erweitern:

# grep xchat /var/log/audit/audit.log | audit2allow
allow xguest_t ircd_port_t:tcp_socket name_connect;

Aus anderen Policy-Entwicklungen weiß ich, dass für den Zugriff auf die meisten Netzwerk-Ports ein Interface zur Verfügung steht, ich überprüfe dies wieder durch das Anhängen der Option »-R« beim Aufruf von »audit2allow« . Und tatsächlich: Nun bekomme ich den Vorschlag, das Interface »corenet_tcp_connect_ircd_port« mit dem Argument »xguest_t« zu verwenden. Hänge ich jetzt noch mittels der Option »-M« einen Modulnamen an das Tool an, so erzeugt es mir direkt ein fertiges Policy-Modul, das ich zum Standardregelwerk hinzufügen kann.