Mit einer vernünftigen Backup-Strategie wappnen sich Administratoren erfolgreich gegen Datenverluste und längere Systemausfälle. So zeigen wir Ihnen ... (mehr)

SELinux-Kategorien

Neben dem SELinux Type-Enforcement, das primär dafür dient, den Zugriff von Containern auf das Host-System einzuschränken, unterstützt Docker auch die sogenannte Multi-Category-Security (MCS). Hierbei geht es vor allem darum, Container untereinander abzuschotten und lediglich Zugriff auf die Container-eigenen Ressourcen zu ermöglichen, aber nicht auf Ressourcen eines anderen Containers zurückgreifen zu können. Die bereits beim Libvirt-Framework eingesetzte Technik sVirt weist hierfür jedem Container zwei zufällige Kategorien zu. Ein Zugriff ist nun lediglich auf Objekte möglich, die ebenfalls über diese beiden Kategorien verfügen. Die Kategorien sind dabei Teil des SELinux-Labels und der Docker-Service kümmert sich darum, sämtliche Objekte, die zu einem Container gehören, mit diesen Kategorien zu versehen. Container-Prozesse bekommen diese Kategorien natürlich ebenfalls dynamisch beim Starten zugewiesen.

Innerhalb eines Container haben sämtliche Ressourcen diese Kategorien zugeordnet bekommen und ein Zugriff ist somit problemlos möglich:

 

Würde der Zugriff auf Ressourcen mit einer anderen Kategorie erfolgen, schlüge dieser fehl. Hierfür wieder ein Beispiel: Zwei Dateien verfügen über das gleiche SELinux-Label svirt_sandbox_file_t. Wir haben soeben gesehen, dass Container auf Objekte von diesem Typen zugreifen können. Da die Datei »/tmp/shadow-container1« aber zu einem anderen Container gehört als die Datei »/tmp/shadow-container2« , verfügen diese jeweils über unterschiedliche Kategorien:

 

Der Container1 läuft in der SELinux-Domäne svirt_lxc_net_t und hat die Kategorien c868 und c981 zugewiesen bekommen. Mittels »runcon« wird der Zugriff wieder entsprechend simuliert:

 

 

 

Würde der Zugriff auf die Datei »/tmp/shadow-container2« von einem Prozess mit dem SELinux-Label system_u:system_r:svirt_lxc_net_t:s0:c111,c323 erfolgen, so wäre dieser erfolgreich und das Auslesen der Datei »/tmp/shadow-container1« würde in diesem Falle fehlschlagen.

Eigene SELinux-Domäne

Innerhalb eines Containers laufen alle Prozesse innerhalb der Domäne svirt_lxc_net_t. Dieser Domäne ist es gestattet, sich an jeden beliebigen Netzwerkport zu binden. Dies ist weniger restriktiv, als wenn ein Netzwerkdienst auf dem Host laufen würde, da dort ganz klar definiert ist, an welchen Port sich dieser binden kann:

 

Seit der Docker-Version 1.3 ist es nun möglich, die SELinux-Domäne, in der Container-Prozesse ablaufen, beim Starten des Containers selbst zu definieren. Notwendig ist hierfür jedoch ein eigenes Policy-Modul, das zuvor in den Security-Server des Kernels geladen werden muss. Dieses Policy-Modul muss die neue SELinux-Domäne definieren und festlegen, welche Rechte diese Domäne und somit die Prozesse, die in dieser ablaufen, erhalten sollen.

Listing 1 zeigt ein Beispiel für ein solches Policy-Modul, das dafür sorgt, dass Postfix-Prozesse innerhalb eines Containers in der Domäne docker_postfix_t ablaufen und sich nur an den Netzwerkport binden können, der in der Policy definiert wurde. Hier also smtp_port_t, was den Ports 25, 465, 587 entspricht.

Listing 1: Policy-Modul docker_postfix.te

 

Nach der Installation des Pakets selinux-policy-devel können Sie dieses Modul in eine binäre Version übersetzen, bevor Sie es anschließend in den Security-Server laden (Listing 2).

Listing 2: Laden des Moduls in den Security-Server

 

Schließlich starten Sie den Container, in dem der Postfix-Service laufen soll, mit den folgenden Kommandos:

 

Um sicherzustellen, dass der Postfix-Server alle notwendigen Zugriffsrechte bekommt, sollten Sie im Anschluss das Audit-Log überwachen und eventuell fehlende Rechte dem Policy-Modul hinzufügen. Hierfür können Sie auf das Tool audit2allow zurückgreifen:

 

Anschließend erhöhen Sie die Versionsnummer in der Type Enforcement-Datei, übersetzen das Modul wie oben gezeigt und laden es mit »semodule -u docker_postfix.pp« erneut in den Security-Server. Wenn Sie sicher sind, dass der Postfix-Service ohne Probleme funktioniert, können Sie auch die permissive Anweisung aus dem Modul entfernen und somit sicherstellen, dass der Kernel die im Modul definierten Regeln auch tatsächlich umsetzt.

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