スレッドを使用できますか？
はい、Sandbox2 ではスレッドがサポートされています。
すべてのスレッドをサンドボックス化する必要があります
Linux の仕組みにより、seccomp-bpf ポリシーは現在のスレッドにのみ適用されます。つまり、ポリシーは他の既存のスレッドには適用されませんが、将来のスレッドはポリシーを継承します。
execve()の前にサンドボックスが有効になっている最初のモードで Sandbox2 を使用している場合、すべてのスレッドがポリシーを継承するため、問題はありません。これが推奨されるサンドボックス モードです。- エグゼキュータが
set_enable_sandbox_before_exec(false)を持ち、Sandboxee がSandboxMeHere()でサンドボックス化するタイミングをエグゼキュータに通知する第 2 モードを使用している場合は、フィルタがすべてのスレッドに適用されていることを確認してください。そうしないと、サンドボックス エスケープのリスクがあります。悪意のあるコードがサンドボックス化されたスレッドからサンドボックス化されていないスレッドに移行する可能性があります。
Sandboxee はどのようにコンパイルすればよいですか？
静的にリンクされた実行ファイルと比較して、sandboxee を動的にリンクされた実行ファイルにコンパイルすると、許可リストに登録する必要がある syscall（open/openat、mmap など）が大幅に増加します。これらの追加の syscall はすべて、実行時にダイナミック リンカーが呼び出されて共有ライブラリを読み込むために必要です。
ただし、静的リンクされたサンドボックスについては、許可リストに登録する必要があるシステムコールは少なくなりますが、セキュリティ上の影響もあります。ASLR ヒープ エントロピーが 30 ビットから 8 ビットに減少し、エクスプロイトが容易になります。
これは、基本的に次のように要約できるジレンマです。
- 動的: ヒープ ASLR は優れているが、初期コード実行が難しくなる可能性がある。ただし、サンドボックス ポリシーの有効性が低下し、エスケープしやすくなる可能性がある。
- 静的: ヒープ ASLR が不十分で、初期コード実行は比較的容易だが、サンドボックス ポリシーがより効果的で、サンドボックスからの脱出は比較的困難。
これまで、静的リンクされたバイナリは位置独立コード（pie）をサポートしていませんでした。また、Bazel はデフォルトで pie を追加していました。厳密な syscall フィルタを定義するには、Bazel のデフォルト値をオーバーライドする必要がありました。
コンパイラは長年にわたって改善され、現在は static-pie オプションをサポートしています。このオプションでは、位置独立コードを生成するようにコンパイラに指示しますが、pie と比較して、静的にリンクされたすべてのライブラリも含まれるようになります。セキュリティの観点から見ると、static-pie は ASLR エントロピーを（30 ビットから 14 ビットに）削減しますが、これは pie がない以前の状況よりも改善されています。
Bazel はデフォルトで pie を追加し、静的はこれと互換性がないため、リンカー オプション フラグを使用して -static-pie リンカー フラグを cc_binary ルールに渡し、デフォルトをオーバーライドすることを検討してください。
linkstatic = 1,
linkopts=["-static-pie"],
これらのオプションの例については、static の例の BUILD をご覧ください。static_bin.cc は static-pie と静的にリンクされているため、非常に厳格な syscall ポリシーを適用できます。これは、サードパーティのバイナリをサンドボックス化する場合にも有効です。
32 ビット x86 バイナリをサンドボックス化できますか？
Sandbox2 は、コンパイルされたものと同じアーキテクチャのみをサンドボックス化できます。
また、Sandbox2 から 32 ビット x86 のサポートが削除されました。64 ビット x86 エグゼキュータを使用して 32 ビット x86 バイナリをサンドボックス化しようとした場合、または 32 ビット syscall（int 0x80 経由）を行う 64 ビット x86 バイナリをサンドボックス化しようとした場合、どちらもサンドボックス違反が生成されます。この違反はアーキテクチャ ラベル [X86-32] で識別できます。
この動作の理由は、システムコール番号がアーキテクチャによって異なるためです。システムコール ポリシーはエグゼキュータのアーキテクチャで記述されているため、Sandboxee に異なるアーキテクチャを許可するのは危険です。実際、これは一見無害な syscall を許可することにつながる可能性があります。実際には、より有害な別の syscall がサンドボックスをエスケープする可能性があります。
エグゼキュータ プロセスがリクエストできるサンドボックスの数に制限はありますか？
各 Sandboxee インスタンス（forkserver から生成された新しいプロセス）に対して新しいスレッドが作成されます。これが制限の理由です。
Executor は複数の Sandbox の作成をリクエストできますか？
いいえ。1 対 1 の関係があります。Executor インスタンスは Sandboxee の PID を保存し、Sandbox インスタンスへの Comms インスタンスを管理します。
forkserver.cc 内で「Function not implemented」と表示されるのはなぜですか？
Sandbox2 は、比較的新しいカーネルでの実行のみをサポートしています。現在のカットオフは 3.19 カーネルですが、今後変更される可能性があります。これは、TSYNC フラグ付きのユーザー Namespace や seccomp など、比較的新しいカーネル機能を使用しているためです。
本番環境で実行している場合、フリートのほぼ全体が十分に新しいカーネルを実行しているため、これは問題になりません。ご不明な点がございましたら、お問い合わせください。
Debian または Ubuntu で実行している場合、カーネルの更新は次のコマンドを実行するだけで簡単に行えます。
sudo apt-get install linux-image-<RECENT_VERSION>