SELinux in der Praxis

© Pavel Ignatov, 123RF

Schutzschild

Das Schutzschild SELinux lässt immer noch viele Admins zusammenzucken. Dabei ist der Betrieb mittlerweile sehr umkompliziert und schafft einen gewaltigen Mehrwert in Bezug auf die Sicherheit des kompletten Systems. Das Regelwerk den eigenen Wünschen anzupassen, ist auch keine große Kunst mehr.
KVM etabliert sich als Standardlösung zur Virtualisierung unter Linux. Der ADMIN-Schwerpunkt hilft beim Bau virtueller Linux-Maschinen, stellt das ... (mehr)

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:

 

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

 

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

 

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

 

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:

 

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:

 

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.

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite