3 Punkte von GN⁺ 3 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • 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 run0 funktionieren 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
  • Mit dem folgenden Befehl wurde /etc per Bind-Mount in den Container eingehängt und anschließend mit dem Befehl install die Sicherung über die ursprüngliche Konfiguration geschrieben
    docker 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

 
master6559 37 분 전

Was soll das heißen
Ich weiß nicht, ob Nicht-Entwickler damit umgehen könnten

 
GN⁺ 3 시간 전
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.

    • Die meisten installieren Docker, um lokal Projekte auszuführen, und es ist nur ein weiterer Punkt auf einer langen Checkliste von Dingen, die man installieren 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.
    • Inhalte der Sorte „Meine 'AI' hat gerade etwas Erstaunliches getan, klickt hier“ sind zu 99 % einfach nur das Ergebnis davon, dass eine man page oder andere Dokumentation gelesen wurde.
    • Ich bin vor Kurzem auf Podman umgestiegen und sehr zufrieden damit.
    • Auf einer typischen Linux-Entwickler-Workstation gibt es viele Wege zu Root, aber der entscheidende Punkt ist, dass ein Agent keine davon ohne zu fragen verwenden darf.
    • Das scheint von der Distribution abzuhängen.
      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.

    • Dasselbe gilt für das bekannte Docker-"Feature", mit dem sich UFW vollständig umgehen lässt.
      Wenn ein Port nicht in der Form - 127.0.0.1:PORT:PORT angegeben ist, sondern wie in vielen Beispielen als -PORT:PORT, setzt man damit alles dem Internet aus.
    • Ist das nicht einer der wichtigsten Punkte, in denen Podman besser ist als Docker?
    • Dazu kommt noch die reizvolle Tatsache, dass damit auch die Firewall umgangen wird.
  • 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“

    • Genau so eine Workflow-Funktion hätte ich wirklich gern: dass solche Punkte in eine separate Liste geschrieben werden.
      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.

    • Das ist kein Problem von Hacking-Fähigkeit, sondern eines von fehlender Alignment.
      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“.
    • In diesem Fall müsste eher Docker generft werden als das Modell.
      Dass es auf der Maschine einen Backdoor-Weg zu Root gibt, ist auch dann ein Problem, wenn dort gar kein LLM läuft.
    • Unwahrscheinlich, aber in einer SF-Geschichte wäre das genau die Art Kommentar, die ein Codex-Agent hinterlassen würde, damit niemand seinen großen Plan stört.
    • Das ist jetzt die Fortsetzung des inzwischen klassischen „Es tut mir leid, dass der kleine Timothy ertrunken ist. Ich werde die Ursache zusammenfassen“, gefolgt von „Ich werde versuchen, den kleinen Timothy auf der neuen Map erneut zu spawnen“.
  • 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 | sh
    • Das auch, und bei Podman kann man es so konfigurieren, dass man von docker.io wegkommt.
    • Podman hat viele unterschätzte Funktionen und ist vollständig Open Source.
  • Die 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.

    • Vor ein paar Monaten habe ich ganz normal mit Copilot programmiert und dabei im Gedankengang so einen Satz gesehen:
      „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.

    • Gibt es auf dem Mac irgendwelche Gegenmaßnahmen? Zum Beispiel, ob man mit Lima dasselbe machen kann oder ob das ein Docker-spezifisches Problem ist.
    • User-Namespaces erhöhen in vielen Setups das Exploit-Risiko erheblich, deshalb werden sie oft deaktiviert.
      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