Linuxでプログラムを隔離したい場面は多いのに、実際には「隔離のための準備」が重くて使わなくなることがある。今回紹介する Drop は、その面倒をできるだけ減らしながら、coding agent や第三者が配布するパッケージを安全に試せる rootless sandbox をうたうツールだ。元の作業環境をなるべくそのまま残しつつ、危ないものだけを閉じ込める発想が中心にある。Docker や Podman とは少し違う立ち位置で、日々の開発作業に入り込ませることを狙っているのが面白い。
Drop のサイトは、まず「Linux sandboxing that doesn’t get in your way」という言い方で始まる。つまり、隔離はしたいが、普段使っている環境から離れたくはない、という開発者向けの問題意識が前提にある。説明によると、Drop は rootless の Linux sandbox で、開発者向けに作られている。隔離したい対象は大きく二つで、ひとつは coding agents、もうひとつは PyPI や npm などから入れる第三者のプログラムだ。
coding agents の例としては、権限を広く与えた状態で agent を動かし、OS レベルで Drop 側が権限を制御する使い方が示されている。サイトでは、もし agent が幻覚のように rm -rf ~ を打っても実際の home directory には届かないし、~/.ssh を狙う prompt injection が来てもそこには何もない、と説明している。さらに localhost 上のサービスへの接続も拒否できるとしていて、ローカル環境を見境なく触らせない設計だと分かる。
第三者のプログラムについては、PyPI や npm、あるいは他の入手元からインストールしても、ユーザーアカウント全体を丸ごと渡さない点が強調されている。もし入れたプログラムが悪意あるものだったり、サプライチェーン攻撃で改ざんされていたりしても、被害を sandbox 内に閉じ込めるという考え方だ。
仕組みの説明もかなり具体的だ。Drop は Python の virtualenv から着想を得た disposable な isolated environment を作り、そこに入る形で使う。各 environment には独自の home directory があり、元の home は見えなくなる。しかも Docker や Podman と違って、今使っている Linux distribution をそのまま使うので、コンテナ用の土台を新しく整える作業がいらない。すでにインストール済みのプログラムも sandbox 内で使えるという。
設定は TOML ベースで、どの file、dir、local network service を sandbox に見せるかを指定できる。しかも各 environment は base config を共有するので、いちど基礎設定をしてしまえば、新しい environment を作るたびに毎回設定し直す必要がない。権限面では root を要求せず、Linux の user namespace の中で動き、process、mount、network、IPC、cgroup の各 namespace を使う。さらに実行前には user namespace の capability をすべて落とすので、sandboxed program が bind mount のような特権操作をできないようにしている。加えて gVisor との統合も用意されていて、必要なら user-space kernel 上で動かすことで host kernel への直接アクセスを避け、kernel vulnerability を突かれる可能性をさらに下げられるとしている。
Drop の説明でいちばん現実味があるのは、隔離を「別の世界」に逃がすのではなく、今の distribution の上に重ねるやり方だと思う。Docker は便利だが、実運用ではイメージ作成、ボリューム、ネットワーク、権限、そして「このツールはコンテナの中でどう動くのか」という確認が積み重なる。Drop はそこを少し崩していて、すでに入っているものを活かしながら、危ない部分だけを見えなくする。開発者にとっては、学習コストよりも「今日すぐ使えるか」が重要なので、この方向性はかなり刺さるはずだ。
一方で、普段の環境に近いことは、そのまま安心材料になるとは限らない。むしろ「見慣れた shell で動いているから安全そうに見える」ことが油断につながる場合がある。Drop が home directory を隠し、localhost も絞り、権限を落とすのは、まさにその油断を前提にした設計だと読める。私はここに、ツールの価値があると思う。要するに、人間が雑に扱ってしまいそうな場面を先回りして塞いでいる。
Drop が coding agents を強く意識しているのは興味深い。普通の sandbox は「不審なプログラムを試す」ために語られることが多いが、ここでは相手が自律的にコマンドを発行する agent だ。しかも紹介文では --dangerously-skip-permissions のような、かなり攻めた運用を前提にしている。つまり、agent には広めの行動範囲を与えつつ、最後の防波堤は OS 側で持つ、という考え方だ。
この設計は、AI を使った開発が広がるほど意味を持つと思う。人間が 1 回 1 回コマンドを打つなら、危ない操作に気づいて止める余地がある。しかし agent は、誤った指示や prompt injection に反応して、同じ危険を高速で実行してしまう。rm -rf ~ のような極端な例が挙げられているのは、脅威を誇張したいからではなく、「人間なら気づくかもしれないミスを、agent は平気で通す」という性質を示しているのだろう。ここに OS レベルの隔離を置くのは筋がいい。
第三者パッケージのリスクは以前からあるが、Drop はそれをセキュリティ部門の話ではなく、日々インストールする開発者の話に引き寄せている。PyPI や npm から入れるツールは便利だが、依存関係のどこかが壊れたり乗っ取られたりしたとき、被害は広がりやすい。普通は「怪しいものは使わない」で済ませたくなるが、現実には使わざるを得ない場面がある。
そのときに、インストール先の権限を丸ごと渡さず、被害を sandbox の内側に閉じ込められるのは大きい。私は、ここが Drop のかなり実用的な価値だと思う。未知の CLI ツールや自動生成されたコードを試すたびに、いちいち新しい VM を立てるのは面倒すぎる。その点、Drop は「ちょっと試す」頻度が高い人ほど効く。安全対策は、頑丈であるだけでは続かない。続けられる軽さがないと、結局は使われなくなる。
Drop は rootless で動くだけでもかなり軽いが、必要なら gVisor を使える。ここは単なるオプションに見えて、実は大事だと思う。なぜなら、OS の namespace だけでは守り切れない種類の攻撃があるからだ。gVisor は user-space kernel として振る舞い、host kernel へ直接触らせにくくする。つまり、kernel vulnerability を突くルートをさらに細くする。
私は、こうした多層化は「最強の単一防御」を目指すより現実的だと見ている。開発者向けの sandbox は、完全な閉世界を作るより、用途に応じて防御の厚みを選べるほうが使いやすい。普段は軽い rootless 運用で十分、怪しいものを触るときだけ gVisor を足す、という切り替えができるなら、導入のハードルは下がるはずだ。逆に言えば、Drop は万能ではない。だが、万能を目指さずに「開発の流れを壊しにくい防御」を積み上げている点が、このツールのいちばんの魅力だと思う。
