ソフトウェアサンドボックス入門：Linux namespacesはなぜ危険なのか
Software Sandboxing: The Basics
ソフトウェアサンドボックスの実装は未開の領域だ。Emiluaのサンドボックスサポート開発で得た経験から、Julien TinnesとChris Evansによる2009年の定義を出発点に、プログラムによる特権降格、rootなしでの特権降格、任意の特権降格という3つの要件を解説。特にLinux namespacesの危険性を指摘し、Andy Lutomirskiの警告を引用しながら、代わりにアクターモデルとケイパビリティベースセキュリティに基づく設計を提案する。
私は、CLONE_NEWUSERを使って任意のネットワーク名前空間上でCAP_NET_ADMINを取得し、それによってネットワーク設定APIにアクセスできることを、大きなリスクだと考えている。例えば、非特権ユーザーがiptablesをプログラムできる。そこに特権昇格が存在しないなら、私は自分の帽子を食べてやる。
HNでの議論
16- 10000truths
特権を落とす必要があること自体、プロセス生成APIがデフォルトで継承するケイパビリティセマンティクスを持つことの自然な結果だ。既存ソフトウェアとの互換性を必要としなければ、こんな風に新しいVMやOSを構築することは決してないだろう。安全な解決策は常にデフォルト何もなしのセマンティクスであり、プロセス生成APIの明示的な引数を介してホワイトリスト化されたケイパビリティを付与するものだ。
Linuxでそのモデルに最も近づけるのはseccompのstrictモードで、これはread()、write()、exit()、sigreturn()以外のすべてのシステムコールを禁止する。これは多かれ少なかれ、プロセスを「純粋な計算/メモリ」に制限する方法だ。その後、プロセスが外界を探りたいのであれば、seccomp呼び出しの前に継承したファイルディスクリプタを読み書きすることによってのみ可能だ。その上にRPCを構築して「ホワイトリスト」をエミュレートし、アクセス制御と制限/ポリシーは反対側でリッスンしているものによって強制できる。
- sieve
先月、LLMが基本的な境界を尊重できないのを見て、サンドボックス化に興味を持った。まあ、そもそも彼らが尊重するだろうという期待自体が愚かだったのだが。
私はアプリケーションレベルのサンドボックス化のファンではない。JVMはセキュリティマネージャで試み、Denoはallow/denyで試みたが、私には十分に汎用的ではない。ある時点で、マシン上で実行するものはすべて壊れているか侵害されている可能性があると仮定し、リスク許容度に応じて状況に対処する必要がある。
これは私がブログで書いた長い話だが、私が構築したサンドボックス化ツールにはBubblewrap + seccomp + socatのルートを選んだ。これにより、ハーネスやコンパイラ、さらにはヘッドレスFirefoxをサンドボックス内で実行でき、システムのあちこちに損害を与える心配がない。