2015-08-27 4 views
7

Ich habe schon viel Tinte darüber gesehen, dass Docker nicht ausreichend isoliert ist, um beliebige Container in einer Multi-Tenant-Umgebung laufen zu lassen, und das macht Sinn. "Wenn es in Docker root ist, betrachte es als Root im Host-Rechner." Was ist jedoch mit Nicht-Root?Welche potenziellen Sicherheitsprobleme führen nicht vertrauenswürdigen Code in einem Docker-Container als Benutzer ohne Rootberechtigung aus?

Wenn ich etwas nicht vertrauenswürdigen Code nehmen und in einem Container ausführen möchte, kann es sicher ausgeführt werden, solange der Container als nicht root-nicht-sudo-Benutzer ausgeführt wird? Was sind die möglichen Sicherheitslücken, wenn man so etwas macht?

Ich bin ziemlich sicher, dass es Produktionsanwendungen gibt, die das heute tun (CI-Systeme, lauffähige Pastebins), aber sind sie nur glücklich, keinen entschlossenen Angreifer gehabt zu haben, oder ist das in einem Produktionssystem vernünftig?

+0

+1 Wirklich interessiert an den Antworten zu diesem. Ich könnte freiwillig das Ausführen als root gibt Ihnen Schreibzugriff auf Systemdateien, die Teil des Docker-Bild sind. Ich denke, ein fantasievolles Stück Malware könnte dies nutzen, um eine Sicherheitslücke auszunutzen, die im Kernel des Docker-Hosts vorhanden sein könnte. –

+3

Ich stimme für das Schließen dieser Frage als Off-Topic (obwohl es ein interessantes ist). Es wird am besten unter security.stackexchange.com beantwortet werden – oleksii

+0

Es ist in Ordnung, Docker Administrator Fragen auf SO post. Es wurde mehrfach diskutiert: http://meta.stackexchange.com/search?q=docker –

Antwort

1

Ab Docker v1.12, wenn man einen Container als Nicht-Root-Benutzer mit Benutzernamensraum aktiviert ausgeführt wird, gibt es zwei Ebenen von Privilegieneskalation ein böswilliger Schauspieler, um ausführen muss root auf dem Host zu werden:

  1. Escalate aus nicht-Wurzel zu Wurzel Benutzern innerhalb des Behälters
  2. Escalate Benutzer im Behälter root-Benutzer auf dem Host zu verankern

also bei nicht vertrauenswürdiger Code innerhalb eines Docker Behälters als nicht-root aus Benutzer wird es für einen atta etwas schwieriger sein cker wird Root auf dem Host, da wir einen zusätzlichen Schritt hinzufügen, um root innerhalb des Containers zu werden. Dies ist der einzige Vorteil in Bezug auf Sicherheit im Vergleich zum Ausführen von Containern mit Root-Rechten.

Bei Privilegieneskalation durch beiden Schichten der Sicherheit nach sollte die Angriffsfläche helfen beschränken:

  1. Workloads (insbesondere Container Andockfenster in diesem Zusammenhang) mit verschiedenen Vertrauensstufen sollten voneinander getrennt werden durch Verwendung von Overlay-Netzwerken nach dem Prinzip der geringsten Rechte.
  2. verfügbar Linux Aktivieren der Sicherheitsmodul in Erzwingungsmodus (zB SELinux, AppArmor)

Referenzen:

0

Alle Container teilen sich den gleichen Kernel. Falls Ihr nicht vertrauenswürdiger Code einen Kernel-Exploit ausführen kann, kann er auf dem Host und/oder anderen laufenden Containern tun, was er will.

Verwandte Themen