Zugriff auf den Docker-Socket ist Root auf dem Host: was das Einbinden in einen Container wirklich gewährt

Worum es geht

Die Sicherheitsdokumentation von Docker besagt, dass der Daemon Root-Rechte benötigt, sofern nicht der Rootless-Modus verwendet wird, und dass nur vertrauenswürdige Nutzende ihn kontrollieren dürfen. Der genannte Grund: Docker erlaubt es, ein Verzeichnis zwischen Host und Container zu teilen, ohne die Zugriffsrechte des Containers zu beschränken, sodass ein Container mit eingebundenem / des Hosts gestartet werden kann und das Dateisystem des Hosts frei verändern kann.

Der Unix-Socket /var/run/docker.sock ist der übliche Steuerkanal. Wer immer darauf schreiben kann, kontrolliert den Daemon.

Warum es wichtig ist

Mehrere gängige Aufbauten vergeben diese Kontrolle, ohne es zu sagen:

• Das Einbinden des Sockets in einen Container, damit dieser andere Container verwalten kann (CI-Runner, Dashboards, Reverse-Proxys, die Labels lesen, Agenten-Sandboxes, die Geschwister-Container erzeugen). Eine Kompromittierung dieses Containers wird zu einer Kompromittierung des Hosts.
• Die docker-Gruppe: Mitgliedschaft entspricht faktisch Root auf der Maschine.
• Die TCP-API ohne TLS-Client-Authentifizierung, die dasselbe an alle im Netzwerk vergibt.

Für Agenten ist der Socket attraktiv, weil er «dies in einem Container ausführen» einfach macht; das bedeutet aber auch, dass die Sandbox sich mit einem einzigen API-Aufruf selbst entkommen kann.

So wird es angewendet

• Inventarisieren, welche Container den Socket einbinden: docker inspect auf allen Containern ausführen und in den Mounts nach dem Socket-Pfad suchen.
• Wo ein Werkzeug nur Container-Metadaten liest, einen filternden Proxy vor den Socket setzen, der nur die benötigten Read-only-Endpunkte erlaubt, und stattdessen diesen einbinden.
• Agenten-Sandboxes, die Container starten müssen, mit Rootless-Modus, einem separaten Daemon oder einer VM-Grenze betreiben statt mit dem Host-Daemon.
• Die docker-Gruppe so klein wie die sudoers-Liste halten und beide zusammen überprüfen.
• Die API nie ohne gegenseitige TLS-Authentifizierung über TCP offenlegen; SSH-Zugriff auf den Socket bevorzugen.

Stolpersteine

• Ein Read-only-Bind-Mount des Sockets (:ro): Er verhindert das Ersetzen der Socket-Datei, nicht das Senden von API-Anfragen über ihn.
• Anzunehmen, dass User-Namespaces oder ein Nicht-Root-Nutzer im Container helfen; der die Anfrage ausführende Daemon bleibt Root.