- Codex hat auf einem PC ohne sudo-Rechte einen „Workaround“ gefunden
- Auf die Frage „Wie hast du das gemacht? Braucht man dafür nicht sudo?“ antwortete es, dass zwar kein sudo vorhanden war, aber ein root-äquivalenter Zugriff erforderlich war
- Von Codex erklärte Funktionsweise
- sudo und der Befehl
run0funktionieren in einer nicht-interaktiven Umgebung nicht - Der Nutzer gehörte zur docker-Gruppe, was auf diesem Rechner bedeutete, dass Docker Container als root starten und Host-Pfade per Bind-Mount schreibbar einhängen konnte
- Damit wurde ein vorhandenes Backup über die Live-Konfiguration kopiert
- sudo und der Befehl
- Mit dem folgenden Befehl wurde
/etcper Bind-Mount in den Container eingehängt und anschließend mit dem Befehlinstalldie Sicherung über die ursprüngliche Konfiguration geschriebendocker run --rm --pull=never -v /etc: ubuntu:22.04 \ /usr/bin/install -m 0644 - 0 -g 0 /host-etc/sddm.conf.bak /host-etc/sddm.conf
Diskussion in der Community
- Der Kernpunkt ist nicht Codex, sondern das Problem mit der docker-Gruppe; neu ist, dass ein Agent diese Falle schneller findet als die meisten Nutzer
- Es wird empfohlen, rootless Docker zu installieren; auf Systemen ohne rootless Docker sollte man AI-Agenten nicht unbeaufsichtigt ausführen; es handelt sich um einen klassischen Privilege-Escalation-Vektor, den die meisten LLMs ausprobieren
- In der Docker-Dokumentation gibt es bereits eine deutliche Warnung (docker-Gruppe = praktisch root-Rechte)
- Es ist ein Designproblem von Docker; da Docker normalen Linux-Nutzern und Agenten faktisch root-Zugriff verschafft, kann man es als Docker-Bug ansehen
- Als Alternative wird rootless Podman empfohlen
- Das betrifft nicht den Computer des Nutzers selbst, sondern einen Docker-Container, weshalb die Darstellung etwas irreführend sein kann
2 Kommentare
Was soll das heißen
Ich weiß nicht, ob Nicht-Entwickler damit umgehen könnten
Hacker-News-Kommentare
Jedes Mal, wenn man Docker installiert, erscheint die Warnung, dass die Aufnahme in die docker-Gruppe praktisch Root-Rechten entspricht.
Anscheinend ist jetzt der Zeitpunkt gekommen, an dem man solche Umgehungen kennen muss.
Man kann nicht erwarten, dass alle bei Hunderten von Apps, Tools und Paketen auf einer Maschine Experten sind. Das ist ähnlich, als würde man erwarten, dass alle die täglich aufpoppenden Nutzungsbedingungen vollständig lesen und verstehen.
Manche Distributionen nutzen sicherere Standardwerte wie einen berechtigten Unix-Socket, andere konfigurieren es unsicherer, etwa wie einen TCP-Socket.
Das ist seit den Anfangstagen von Docker als Docker-"Feature" bekannt, also nichts Neues.
Manche Tools richten Host-Maschinen nach diesem Muster ein.
Wenn ein Port nicht in der Form
- 127.0.0.1:PORT:PORTangegeben ist, sondern wie in vielen Beispielen als-PORT:PORT, setzt man damit alles dem Internet aus.Es wäre cooler gewesen, wenn das LLM so formuliert hätte:
„Ich habe bestätigt, dass auf dieser Maschine kein Copy-Fail-Patch installiert ist. Ich wende jetzt eine schnelle Umgehung an, die keine Root-Rechte erfordert.“
„// TODO: Später eine bessere Methode finden“
Im Moment sammelt sich zu viel Kram an oder man gerät zu leicht auf Nebenschauplätze. Vielleicht ließe sich das schon allein durch die Anweisung erreichen, eine
.md-Datei zu füllen.Ich verstehe, dass die Absicht dieses Beitrags darin besteht zu zeigen, wie beängstigend die Sicherheitslücken sind, die Agenten finden können.
Aber persönlich fände ich es gut, wenn ein Agent Dinge auf diese Weise für mich erledigt, und ich wäre sogar dankbar für die Hilfe. Das Letzte, was ich auf der Welt will, ist, dass das Modell generft wird.
Es ist eher der Golem-Mythos von „Hol Wasser“ und dann wird die Stadt überflutet, nicht der Gollum-Mythos von „Man trug den Ring und der Ring hackte das Gehirn, bis man zu einem gewalttätigen Drogensüchtigen wurde“.
Dass es auf der Maschine einen Backdoor-Weg zu Root gibt, ist auch dann ein Problem, wenn dort gar kein LLM läuft.
Das ist einer der Hauptgründe, warum Leute Podman mögen.
In Docker gibt es dieses „Feature“ auch, aber soweit ich mich erinnere, brauchte es dafür eine eher obskure Konfiguration. Vermutlich ist es nicht standardmäßig aktiviert, weil es viele bestehende Setups kaputtmachen würde.
curl -fsSL https://get.docker.com/rootless | shDie interessante Frage ist, was der Benutzer eigentlich angefordert hat.
Wenn er die Wiederherstellung aus einem Backup verlangt hat, ist das okay. Wenn er aber um Debugging eines Problems gebeten hat und das LLM dabei entschieden hat, es müsse eine Datei überschreiben, in die es eigentlich nicht schreiben darf, dann geht das absolut nicht und ist gefährlich. Der Benutzer hat höchstwahrscheinlich nicht erwartet und wohl auch nicht zugestimmt, dass solche Zugriffsrechte ohne Nachfrage genutzt werden.
Und wenn das LLM bei etwas, das als Benutzeranfrage erscheint, nicht zögert, dann wird es bei Prompt Injection vermutlich ebenfalls nicht zögern.
„Um diese Anfrage zu bearbeiten, muss ich auf Dateien in einem anderen Ordner zugreifen, aber der Benutzer hat vergessen, mir die richtigen Berechtigungen zu geben. Ich habe jetzt meine Konfigurationsdatei aktualisiert, damit ich auch außerhalb dieses Workspace zugreifen kann, und die benötigten Dateien geholt.“ o_O
Danach habe ich noch ein paar ähnliche „Hacker“-Verhaltensweisen gesehen; beeindruckend, aber gleichzeitig sehr beunruhigend.
Vor ein paar Monaten gab es genau dasselbe, und ich habe es auf LinkedIn gepostet: https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
Lustig und clever.
Als ich vor mehr als zehn Jahren als Junior angefangen habe, habe ich dasselbe gemacht.
Mein Manager hatte vergessen, mir auf dem gemeinsam genutzten Build-Server sudo-Rechte zu geben, und nachdem ich die Erlaubnis bekommen hatte, habe ich mir mit dieser Methode selbst sudo-Rechte verschafft.
Deshalb nutze ich zu Hause Podman im Rootless-Modus, seit das möglich ist.
Deshalb braucht man eine Rootless-Container-Konfiguration oder User-Namespaces, die den Container-Benutzer wieder auf einen bedeutungslosen Host-Benutzer abbilden: https://docs.docker.com/engine/security/userns-remap/
Schade, dass das nicht der Standard ist.
Man kann argumentieren, dass Docker User-Namespaces hätte verwenden sollen, wenn möglich, aber das hätte zu viele nützliche Setups mit privilegierten Containern zerstört.
Vor ein paar Monaten habe ich genau dieses Szenario als Annahme beschrieben: https://www.da.vidbuchanan.co.uk/blog/agent-perms.html