スレッドは使用できますか？
はい。サンドボックス 2 ではスレッドがサポートされています。
すべてのスレッドをサンドボックス化する必要がある
Linux の仕組み上、seccomp-bpf ポリシーは現在のスレッドにのみ適用されます。つまり、ポリシーは他の既存のスレッドには適用されませんが、以降のスレッドには継承されます。
execve()より前にサンドボックス化が有効になっている最初のモードで Sandbox2 を使用している場合、すべてのスレッドがポリシーを継承するため、問題はありません。これはサンドボックス化の推奨モードです。- エグゼキュータが
set_enable_sandbox_before_exec(false)で、SandboxMeHere()でサンドボックス化したいときに Sandboxee がエグゼキュータに指示する 2 つ目のモードを使用している場合は、フィルタがすべてのスレッドに適用されることを確認してください。そうしないと、サンドボックス化されたスレッドからサンドボックス化されていないスレッドに悪意のあるコードが移行される可能性があるため、サンドボックスのエスケープのリスクがあります。
Sandboxee はどのようにコンパイルすればよいですか？
注意しないと、多くの依存関係や副作用（追加のシステムコール、ファイル アクセス、さらにはネットワーク接続）を継承しやすくなり、サンドボックス化（すべての副作用の追跡）と安全性の低下（システムコールやファイル ポリシーの範囲が広いため）につながります。次のようなコンパイル オプションを使用すると、このような問題を軽減できます。
- Sandboxee バイナリを静的にコンパイルして、多くのシステムコール（
open/openat、mmapなど）を使用する動的リンクを回避しました。 Bazel ではデフォルトで
pieが追加されますが、static は互換性がないため、cc_binary ルールの以下のオプションを使用して、features フラグを強制的に使用させることを検討してください。linkstatic = 1, features = [ "fully_static_link", # link libc statically "-pie", ],
ただし、static を使用することには、ASLR ヒープ エントロピーが 30 ビットから 8 ビットに減少し、悪用が容易になるという欠点があります。サンドボックスの実装とポリシーに応じて、何が適切か慎重に決定します。
- 静的でない: ヒープの ASLR が優れています。最初のコード実行が難しい可能性がありますが、サンドボックス ポリシーの効果が低くなり、簡単に抜け出せる可能性があります。
- static: ヒープの ASLR が低い。初期コード実行は容易になる可能性があるが、サンドボックス ポリシーはより効果的で、解除が困難になる可能性がある。
コンパイラが静的 PIE（Position Independent Executables）をサポートしていないため、これは残念な選択です。PIE はバイナリを動的オブジェクトとすることで実装され、ダイナミック ローダは実行前にバイナリをランダムな場所にマッピングします。従来、ヒープはバイナリのベースアドレスの後のランダムなオフセットに配置される（そして brk syscall で展開される）ため、静的バイナリの場合、ヒープの ASLR エントロピーは PIE がないため、このオフセットのみとなります。
これらのコンパイル オプションの例については、BUILD.bazel という静的の例をご覧ください。static_bin.cc は静的にコンパイルされるため、非常に厳しいシステムコール ポリシーを設定できます。これは、サードパーティ バイナリのサンドボックス化にも適しています。
32 ビット x86 バイナリをサンドボックス化できますか？
Sandbox2 は、コンパイルに使用したアーキテクチャと同じアーキテクチャのみをサンドボックス化できます。
また、Sandbox2 から 32 ビット x86 のサポートが削除されました。64 ビット x86 エグゼキュータを使用して、32 ビット x86 バイナリ、または 32 ビット システムコールを作成する 64 ビット x86 バイナリを（int 0x80 を介して）サンドボックス化しようとすると、どちらもサンドボックス違反になります。この違反はアーキテクチャ ラベル [X86-32] で識別できます。
この動作の背後にある理由は、システムコール番号がアーキテクチャによって異なるためです。また、システムコール ポリシーはエグゼキュータのアーキテクチャで作成されているため、Sandboxee で別のアーキテクチャを許可すると危険です。実際、これは一見無害に見えるシステムコールの許可につながり、実際には、別のより有害なシステムコールによってサンドボックスが脱出に至るおそれがあることにもつながります。
エグゼキュータ プロセスがリクエストできるサンドボックスの数に制限はありますか？
Sandboxee インスタンス（forkserver から生成される新しいプロセス）ごとに、新しいスレッドが作成されます。そこには制限があります。
エグゼキュータは複数のサンドボックスの作成をリクエストできますか？
いいえ。1 対 1 の関係があります。たとえば、Executor インスタンスが Sandboxee の PID を格納し、Comms インスタンスをサンドボックス インスタンスに対して管理します。
forkserver.cc に「Function not を実装」と表示されるのはなぜですか？
Sandbox2 は、比較的新しいカーネルでの実行のみをサポートします。現時点では 3.19 カーネルがカットオフですが、今後変更される可能性があります。これは、ユーザー名前空間や seccomp といった比較的新しいカーネル機能を TSYNC フラグとともに使用しているためです。
本番環境で実行している場合、フリートのほぼ全体が新しい十分なカーネルを実行しているため、これは問題ではありません。問題が発生した場合は、お問い合わせください。
Debian や Ubuntu 上で稼働している場合、以下のコマンドを実行するだけでカーネルを更新できます。
sudo apt-get install linux-image-<RECENT_VERSION>