© Ahmet Ihsan Ariturk, 123RF

In dem Maße, wie Containerlösungen wie Docker in Unternehmen immer mehr Anwender finden, rücken Sicherheitsaspekte stärker in den Fokus. Schon länger bescheinigen Kritiker Docker Schwächen in diesem Bereich. Doch wo genau hat sich das Projekt verhoben?

Bei Docker (Abbildung 1, [1]) – so scheint es – hinkt die Sicherheit der Beliebtheit hinterher. Zwar setzen immer mehr Unternehmen Docker im Rechenzentrum ein, doch Technologien, mit denen Admins die Container absichern, etablieren sich nur langsam. Oft reißen gerade jene Features, die Docker beliebt machen, zugleich Sicherheitslücken auf.

Abbildung 1: Die Webseite von Docker preist ihre Container als Instant-Lösung.

Was der Kernel nicht isoliert

Docker nutzt die Fähigkeit des Linux-Kernels, voneinander isolierte Umgebungen zu schaffen, in denen Anwendungen laufen. Diese Container sind schlank, weil sie sich denselben Kernel teilen, werkeln aber dank Cgroups [2] und Namespaces [3] in eigenständigen Laufzeitumgebungen. Sie legen die von einem Container nutzbaren Ressourcen fest, zugleich sieht nur der Container selbst bestimmte Prozesse und Netzwerkfunktionen.

Während aber ein Angreifer aus einer gekaperten VM heraus kaum mit dem Kernel des Hosts interagieren kann, hält die Container-Isolation weniger dicht. Der Angreifer erreicht hier wichtige Kernel-Subsysteme wie SE Linux [4] und Cgroups sowie »/sys« und »/proc« . So kann er potenziell Sicherheitsfeatures des Hosts umgehen.

Zugleich verwenden Container den gleichen User Namespace wie ihr Hostsystem. Läuft also ein Prozess im Container mit Rootrechten, behält er diese auch, wenn er mit dem Kernel oder eingebundenen Dateisystemen interagiert. Admins lassen Software in Containern daher besser nicht mit Rootrechten laufen, was ohnehin nur selten nötig ist.

Risiko: Dockers Daemon

Der Docker-Daemon aber braucht Rootrechte. Er verwaltet die Container auf dem Host und muss mit dem Kernel reden, der die isolierten Umgebungen bereitstellt. Nutzer, die den Daemon einsetzen, erhalten so einen privilegierten Zugriff auf das System. Das ist insbesondere kritisch, wenn ein Hoster erwägt, Container über eine Weboberfläche im Selfservice anzubieten.

Es gäbe zwar die Möglichkeit, die Gruppe »docker« zu verwenden. Die aber bringt kaum mehr Sicherheit, da ihre Mitglieder Container erstellen dürfen, in denen erstens wiederum eine Rootshell läuft und die zweitens das Host-Dateisystem einbinden. Hier bleibt nur, den Zugriff auf den Docker-Dienst streng zu reglementieren, um eine unerwünschte Rechte-Ausweitung zu vermeiden.

Des Weiteren kann Dockers Daemon über ein REST-API via HTTP(S) kommunizieren. Wer diese Funktion [5] nutzt, sollte den Zugriff auf das API auf ein vertrauenswürdiges Netz begrenzen oder ihn über SSL-Client-Zertifikate oder Ähnliches einschränken.

Gegenmaßnahmen

Neue Versionen von Docker bringen Features mit, um die genannten Angriffsszenarien abzuschwächen. Das »/sys« -Dateisystem sowie wichtige Dateien in »/proc« bindet Docker nur-lesbar ein. Sie lassen sich vom Container aus nicht beschreiben, was verhindert, dass privilegierte Prozesse in Containern das Hostsystem manipulieren.

Der Kernel unterteilt die Privilegien von Root in so genannte Capabilities [6] und weist sie den Prozessen jeweils einzeln zu. Standardmäßig blockiert Docker wichtige Capabilities, um privilegierte Prozesse im Container daran zu hindern, dem System Böses zu tun. Dazu zählen die Netzwerkkonfiguration, das Laden von Kernelmodulen oder der Zugriff auf das Audit-Subsystem. Benötigt eine spezielle Anwendung die blockierten Capabilities, erlaubt Docker sie für einen bestimmten Container.

SE Linux grenzt ab

SE Linux [4] ist ein Sicherheitsframework, das jeder Datei und jedem Prozess mehrteilige Label zuweist. Eine Policy bestimmt, welches Prozesslabel auf welche Dateilabel zugreifen darf. Docker kennt zwei Varianten: Type Enforcement und Multi Category Security (MCS).

Mit Type Enforcement schränkt es den Zugriff von Containern auf das Host-Dateisystem ein. Alle Containerprozesse laufen mit dem gleichen Typ. Der erlaubt zwar den Zugriff auf Dateien im Container und auf einige Dateien des Hostsystems, verbietet ihn aber für die meisten Ordner auf dem Hostsystem (»/var« , »/root« , »/home« ).

Käme nur Type Enforcement zum Einsatz, könnten die Container jedoch problemlos auf die Daten anderer Container zugreifen. Dank MCS weist SE Linux einem Container beim Start ein zufälliges MCS-Label zu, mit dem der Docker-Daemon alle Dateien des Containers versieht. Der Kernel verhindert, dass Prozesse mit einem anderen MCS-Label auf die Dateien eines Containers zugreifen.

In vielen Unternehmen galt SE Linux lange Zeit als unbeliebtes Feature, das Admins gern per Default abschalten. Für die Sicherheit von Docker-Containern sind Features wie Secure Virtualization (S-Virt, [7]) hingegen unverzichtbar. Letztgenanntes verhindert fast im Alleingang, dass Nutzer anderer Container die eigenen Dateien lesen.

Blick in die Zukunft

Für die Zukunft planen die Docker-Entwickler, die Container-Sicherheit und -Isolation weiter zu verbessern. Helfen sollen dabei vor allem drei Funktionen: User Namespaces, Seccomp [8] und Role Based Access Control (RBAC, [9]) beim Zugriff auf den Docker-Daemon.

Die User Namespaces genießen dabei Priorität. Hierbei mappt Docker Benutzer-IDs vom Container auf andere IDs des Hosts. Das soll die Möglichkeiten eines Angriffs auf Dateien, die Root gehören, erheblich einschränken.

Da die Container alle mit demselben Kernel sprechen, kann sich ein Fehler in einer Kernelfunktion als fatal für die Abgrenzung zwischen Host und Container sowie den Containern untereinander erweisen. Seccomp stammt von Google und entzieht einem Prozess den Zugriff auf bestimmte Syscalls. Mit ihnen greift ein Prozess zwar auf den Kernel zu, allerdings braucht er viele der über 600 Syscalls nur selten. Ohne sie ließe sich also die mögliche Angriffsfläche verkleinern. Daniel Walsh arbeitet bei Red Hat an der Containersicherheit. Er schätzt, die Entwickler könnten die Zahl der aufrufbaren Syscalls bis zu 50 Prozent reduzieren [10].

Daneben wollen die Entwickler den Zugriff auf den Docker-Dienst verfeinern und Authentifizierungs-Möglichkeiten ergänzen. Dadurch könnten auch Nutzer von dem Dienst Gebrauch machen, die auf dem Host keine Rootberechtigung besitzen. Führen die Entwickler zudem ein RBAC-System ein, weist der Docker-Admin verschiedenen Nutzern Rollen zu, was diesen nur begrenzte Rechte im Umgang mit dem Daemon verleiht. Mit Hilfe dieser Pläne ließe sich also der Zugriff auf Container oder Funktionen künftig weiter einschränken.

Fazit

In vielen Bereichen haben die Docker-Entwickler bereits reagiert, um die Sicherheit von Containern zu erhöhen, und sie ergänzen auch weiterhin neue Features zur Sicherheit. Mit Version 1.8 und Content Trust [11] wurde vor Kurzem beispielsweise ein Verifikationssystem für Docker-Images eingeführt. Zudem will die Open Container Initiative [12] die Sicherheit stärker berücksichtigen.

Dennoch bleibt künftig einiges zu tun. So fehlt es etwa noch immer an nachhaltigen Best Practices im Containermanagement, um den großflächigen Einsatz in Unternehmen zu fördern.