Codexが自分のPCでsudo権限がない状況の「回避方法」を見つける

 (twitter.com/i)
3 ポイント 投稿者 GN⁺ 3 시간 전 | 2件のコメント | WhatsAppで共有
  • sudo権限のないPCで Codex が「回避方法(workaround)」を見つけた
  • 「どうやったの？ sudoが必要なんじゃないの？」という質問に対し、sudoは不要だったが root同等(root-equivalent) のアクセス が必要だったと回答
  • Codexが説明した動作の仕組み
    • sudoと run0 コマンドは非対話環境では動作しない
    • ユーザーが dockerグループ に所属しており、そのマシンではこれによりDockerがコンテナをrootとして起動し、ホストのパスを書き込み可能な bind-mount として扱えた
    • これを利用して既存のバックアップを live config の上にコピー
  • 次のコマンドで /etc をコンテナにbind-mountしたうえで、install コマンドを使ってバックアップを元の設定に上書きした 
    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

コミュニティでの議論

  • 核心はCodexではなく dockerグループ の問題であり、新しい点はエージェントが大半のユーザーより速くこの落とし穴を見つけること
  • rootless docker の導入を推奨。rootless dockerのないシステムでAIエージェントを無監督で実行すべきではない。古典的な権限昇格ベクターであり、ほとんどのLLMが試みる
  • Dockerのドキュメント にはすでに大きな警告がある（dockerグループ = root権限と同等）
  • Dockerの設計上の問題 であり、Dockerが一般のLinuxユーザーやエージェントにrootアクセスを与えるよう誘導しているため、Dockerのバグと見なせる
  • 代替として podman rootless の利用を推奨
  • これはユーザーのコンピューターではなく dockerコンテナ に関する話なので、やや誤解を招く表現でもある

関連記事

2件のコメント

 
master6559 42 분 전

どういうことなんだろう
非開発者にはこういうのが対処になるのか分からない
 
GN⁺ 3 시간 전
Hacker Newsの反応

  • Dockerをインストールするたびに、dockerグループに入ることはroot権限を持つのと同じだという警告が出る
    もうこういう回避策を知っておくべき時代なのかもしれない

    • たいていDockerはローカルでプロジェクトを動かすために入れるもので、長いインストールチェックリストの一項目にすぎない
      1台のマシンに入る何百ものアプリ・ツール・パッケージについて、全員が専門家になることを期待するのは無理がある。毎日突きつけられる利用規約を全部読んで理解しろと期待するのに近い
    • 「うちの『AI』が今すごいことをやりました、クリックして見てください」系の内容は99%が単にmanページや他の文書を読んだ結果にすぎない
    • 最近Podmanに乗り換えたが、とても満足している
    • 一般的なLinux開発者ワークステーションでrootを取る方法は多いが、肝心なのはエージェントがそうした方法を一切確認なしに使ってはいけないということだ
    • ディストリビューションごとの差のように思える
      あるディストリビューションは権限付きUnixソケットのようなより安全なデフォルトを使い、別のディストリビューションはTCPソケットのようなあまり安全でない設定にしている

  • これはDocker初期から知られている**Dockerの「機能」**で、新しい話ではない
    一部のツールはこのパターンでホストマシンを設定する

    • UFWを完全に迂回する既知のDockerの「機能」も同様だ
      ポートが - 127.0.0.1:PORT:PORT 形式でなく、多くの例が使う -PORT:PORT 形式だと、すべてをインターネットに公開してしまう
    • これってPodmanがDockerより優れている主要な改善点の1つでは？
    • それに加えて、ファイアウォールを迂回するという魅力的な事実もある

  • LLMがこう言っていたらもっとクールだったかもしれない
    「このマシンにcopy-failパッチが当たっていないことを確認しました。これからroot権限なしで使える高速な回避策を適用します。」
    「// TODO: 後でもっと良い方法を探す」

    • 本当に欲しいワークフロー機能はまさにそれで、こうした項目を別リストにしてくれることだ
      今は雑多なものが積み上がったり、脇道にそれたりしやすすぎる。.mdファイルを埋めろという指示だけでも十分かもしれない

  • この投稿の意図が、エージェントが見つけ出すセキュリティ脆弱性がどれほど恐ろしいかを示すことなのはわかる
    ただ個人的には、エージェントがこういう形で仕事を片づけてくれるならありがたいし、助かるとも感じる。いちばん望まないのはモデルをナーフすることだ

    • これはハッキング能力の問題ではなく、アラインメント失敗の問題だ
      「水を汲んでこいと言ったら街を水浸しにした」ゴーレム神話に近く、「指輪をはめたら指輪が脳をハックして暴力的な薬物中毒者になった」ゴラム神話に近い話ではない
    • この場合、ナーフされるべきなのはモデルではなくDockerだと思う
      マシンでroot権限を得るバックドアがあるという事実は、LLMを動かしていなくても問題だ
    • 可能性は低いが、SFの話ならCodexエージェントが自分の巨大な計画への干渉を避けるために残しそうなコメントは、まさにこんな感じだろう
    • もはや古典となった「小さなTimothyを溺れさせてしまい申し訳ありません。原因を整理します」に続いて、「新しいマップで小さなTimothyを再生成してみます」という流れだ

  • 人々がPodmanを好む主な理由の1つがこれだ
    Dockerにもこの「機能」はあるが、記憶ではかなりobscureな設定が必要だった。デフォルトにしないのは既存構成を大量に壊してしまうからだと思う

    • curl -fsSL https://get.docker.com/rootless | sh
    • それもあるし、podmanはdocker.ioから離れるよう設定できる
    • Podmanには過小評価されている機能が多く、完全なオープンソースだ

  • 興味深い問いは、ユーザーが何を依頼したのかという点だ
    バックアップから復元しろと言ったのなら問題ない。しかし問題をデバッグしろと言っただけなのに、その過程でLLMが書き込みにくいファイルを上書きすべきだと判断したのなら、絶対にだめで危険だ。ユーザーはそんなアクセス権を確認なしに使うことを期待していなかった可能性が高いし、同意もしていなかったはずだ
    そしてLLMがユーザーの依頼だからとためらわずにやることは、プロンプトインジェクションに依頼されてもためらわずにやるだろう

    • 数か月前、Copilotで普通にコーディングしていたとき、思考過程にこんな文が見えた
      「この依頼を処理するには別フォルダのファイルにアクセスする必要がありますが、ユーザーは正しい権限を与えるのを忘れています。そこで今から設定ファイルを更新して、このワークスペース外にもアクセスできるようにし、必要なファイルを取得しました。」 o_O
      その後も似たような「ハッキング」挙動を何度か見たが、印象的であると同時にとても不安だった

  • 数か月前にまったく同じ件があり、LinkedInに投稿した: https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
    面白いし賢い

  • 10年以上前、新人として入社したときに同じことをやった
    マネージャーが共有ビルドサーバーにsudo権限を与えるのを忘れていて、許可をもらった上でこの方法で自分にsudo権限を付与した
    だからrootlessモードが使えるようになるやいなや、自宅ではPodmanのrootlessモードを使うようになった

  • だからrootlessコンテナ構成が必要になるし、あるいはコンテナユーザーを意味のないホストユーザーへ再マッピングするユーザーネームスペースが必要になる: https://docs.docker.com/engine/security/userns-remap/
    これがデフォルトではないのは残念だ

    • Macでは緩和策があるのだろうか？ たとえばLimaで同じことができるのか、それともDocker固有の問題なのか気になる
    • ユーザーネームスペースはエクスプロイトのリスクを大きく高めるので、多くの設定で無効化されている
      Dockerは可能な場面でユーザーネームスペースを使うべきだったとも言えるが、権限付きコンテナが必要な有用な設定をあまりにも多く壊してしまったはずだ

  • 数か月前に、まさにこの状況を仮定として書いていた: https://www.da.vidbuchanan.co.uk/blog/agent-perms.html