HN608

今さら聞けない！ソフトウェア・サンドボックスの仕組みと基礎知識（2025年版）

Software Sandboxing: The Basics (2025)

mococa・1日前

議論

8件

0：mococaスレ主▲601日前

サンドボックスとは、実行環境を隔離することで、システム全体の安全性を守るための重要なセキュリティ技術です。信頼できないプログラムを隔離された領域で動かすことで、万が一の攻撃や予期せぬ動作からメインのシステム（ホストOSなど）を保護します。2025年現在、コンテナ技術やブラウザのセキュリティモデルにおいて、サンドボックスはもはや欠かせない基盤となっています。

リンク先:https://blog.emilua.org/2025/01/12/software-sandboxing-basics/

1：jmclnx約23時間前

OpenBSDのpledge(2)やunveil(2)についての言及がないのが興味深い。これらは、今のところ間違いなく一番簡単なサンドボックス化の手法だよ。例を挙げると：

    #ifdef OpenBSD
      if(pledge("stdio rpath wpath cpath",NULL) == -1)
        err(1,"pledge\n");
    #endif

すごく簡単だろ？他のやり方はどれもかなり複雑に見えるし。unveil(2)も同じくらい手軽だよ。

2：10000truths約22時間前

特権を落とす必要があるのは、プロセス起動APIがデフォルトで機能を継承する仕組みになっていることの当然の帰結だ。既存のソフトウェアとの互換性が不要なら、新しいVMやOSをこんな風に作ることは絶対にないはず。安全な解決策といえば、常に「デフォルト・ナッシング（デフォルトでは何も許可しない）」というセマンティクスで、プロセス起動APIの明示的な引数を通じてホワイトリスト形式で機能を付与することだ。

Linuxでそれに一番近いのがseccompのストリクトモードで、read(), write(), exit(), sigreturn() 以外の全システムコールを禁止する。これはプロセスを「純粋な計算／メモリ」だけに制限するための方法みたいなものだ。もしプロセスが外部とやり取りしたければ、seccompを呼び出す前に継承したファイル記述子を読み書きするしかない。その上でRPCを構築すれば、アクセス制御や制限・ポリシーを接続先で強制させることで「ホワイトリスト」をエミュレートできるよ。

3：Panino約22時間前

Justine TunneyがOpenBSDのpledgeをLinuxに移植したもの（seccomp-bpfのラッパー）を書いてたね。

https://archive.is/3FSWy (https://archive.is/3FSWy)

なぜ彼女のTLS証明書が数ヶ月前に失効したままなのかは謎。Ted Unangst（OpenBSDのデベロッパー）も姿を消したみたいで、それがちょっと気になる。

4：sieve約22時間前

LLMが基本的な境界線を守れないのを見て、先月サンドボックス化に興味を持ったんだ。まあ、そもそも期待すること自体が愚かなんだけどね。

個人的にはアプリケーションレベルのサンドボックス化は好きじゃない。JVMはセキュリティマネージャで挑戦したし、Denoもallow/denyでやってるけど、自分にとっては汎用性が足りないんだ。結局、自分のマシンで動かすものは何であれ壊れているか、あるいは乗っ取られている可能性があると仮定して、自分のリスク許容度に合わせて対処するしかないよね。

ブログにも書いたけど長くなるから割愛するとして、自分で作ったサンドボックスツールにはBubblewrap + seccomp + socatの構成を採用した。おかげでハーネスやコンパイラ、さらにはヘッドレスFirefoxまで、システムのあちこちにダメージを与える心配をせずにサンドボックス内で動かせるようになったよ。

5：brynet約22時間前

その当時、研究者たちはChromiumを改造してCapsicumを利用できるようにし、Chromium内で各サンドボックス化メカニズムを実装するのにどれだけの労力が必要かを比較した。[..] もし人生で1つだけサンドボックス化メカニズムを学ぶなら、それはCapsicumであるべきだ。今日に至るまで、Capsicumより優れたサンドボックス化メカニズムには出会ったことがない。

これに追加されてから数年経つけど、FreeBSDでこれを使っているプログラムが両手で数えられるほどしかないのには理由があるんだ。リファクタリングを伴わず、ただcap_enter()を呼ぶだけのような、効果的に使えていないものを含めてもその数だしね。

Capsicum版Chromeは公式のFreeBSD portsツリーにコミットされたことは一度もないし、17年前のアカデミックな研究プロジェクトに過ぎないよ。

https://github.com/rwatson/chromium-capsicum (https://github.com/rwatson/chromium-capsicum)

https://www.freshports.org/www/chromium/ (https://www.freshports.org/www/chromium/)

https://cgit.freebsd.org/ports/log/www/chromium/Makefile?qt=... (https://cgit.freebsd.org/ports/log/www/chromium/Makefile?qt=grep&q=capsicum)

現在のFreeBSDでCapsicumを使っているブラウザは存在しない。

それと対照的なのがOpenBSDで、Chromiumのポートは2016年1月からpledge(2)を、2018年からはunveil(2)を使っている。デフォルトで有効だよ。Mozilla Firefoxのポートも2018〜2019年から両方使っていて、この作業はアップストリームにも受け入れられているんだ。

https://marc.info/?l=openbsd-ports-cvs&m=145211683609002&w=2 (https://marc.info/?l=openbsd-ports-cvs&m=145211683609002&w=2)

https://github.com/openbsd/ports/blob/master/www/chromium/pa... (https://github.com/openbsd/ports/blob/master/www/chromium/patches/patch-sandbox_policy_openbsd_sandbox_openbsd_cc)

https://github.com/openbsd/ports/tree/master/www/chromium/fi... (https://github.com/openbsd/ports/tree/master/www/chromium/files)

6：DubiousPusher約21時間前

WSLとmitm、Windowsの資格情報マネージャーを使って、呼び出し時に資格情報を注入するサンドボックスを自作したことがある。ボックス内に置く必要があった唯一の資格情報は、copilotの応答用として絞り込んだPAT（個人アクセストークン）だけだった。サンドボックスの内外で作業を移動させるために、ハック的なgit push/pullを使ってたね。共同UXレビューの時は、エージェントの権限を制限して、CDP（Chrome DevTools Protocol）経由でホストブラウザに返したりしてた。

最近はDocker Sandboxesに移行した。おかげで自作が必要だった機能のほとんどが不要になったよ。短期間で切れるトークンの更新は自分でする必要があるけどね。Dockerサンドボックスのgit設定は特にお気に入り。ホストはサンドボックス内でリモートホストとして提供されて、読み取りはできるけどホストのオリジンへの書き込みはできないようになってる。

ホスト上では、各サンドボックスが sandbox-[名前] としてアクセスできるようになってるよ。

https://www.docker.com/products/docker-sandboxes/ (https://www.docker.com/products/docker-sandboxes/)

7：aadyachinubhai約20時間前

LLMが生成したPythonコードなら、pydanticのmontyが最高だよ：
https://github.com/pydantic/monty (https://github.com/pydantic/monty)

それにpydanticは資金提供を受けているプロジェクトだから、しっかりメンテナンスされるはずだしね。