スレッドを使用できますか？
はい、Sandbox2 ではスレッドがサポートされています。
すべてのスレッドをサンドボックス化する必要があります
Linux の仕組み上、seccomp-bpf ポリシーは現在のスレッドにのみ適用されます。つまり、ポリシーは他の既存のスレッドには適用されませんが、今後のスレッドはポリシーを継承します。
- `execve()` の前にサンドボックス化が有効になっている最初のモードで Sandbox2 を使用している場合、すべてのスレッドがポリシーを継承するため、問題はありません。
execve()このモードでのサンドボックス化をおすすめします。 - エグゼキュータに
set_enable_sandbox_before_exec(false)が設定されていて、 Sandboxee がSandboxMeHere()でサンドボックス化するタイミングをエグゼキュータに通知する 2 番目の モード を使用している場合は、フィルタがすべてのスレッドに適用されていることを確認してください。そうしないと、サンドボックス エスケープのリスクが生じます。悪意のあるコードがサンドボックス化されたスレッドからサンドボックス化されていないスレッドに移行する可能性があります。
Sandboxee はどのようにコンパイルすればよいですか？
静的にリンクされた実行可能ファイルと比較して、Sandboxee を
動的にリンクされた実行可能ファイルにコンパイルすると、許可リストに登録する必要がある syscall
（open/openat、mmap など）が大幅に増加します。これらの追加の syscall はすべて、共有ライブラリを読み込むために実行時にダイナミック リンカーを呼び出す必要があるために必要となります。
ただし、静的にリンクされた Sandboxee を見てみましょう。許可リストに登録する必要がある 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"],
これらのオプションの例については、
静的サンプル
BUILDをご覧ください。
static_bin.cc は static-pie と静的にリンクされているため、
非常に厳密な syscall ポリシーを設定できます。これは、サードパーティのバイナリをサンドボックス化する場合にも適しています。
32 ビット x86 バイナリをサンドボックス化できますか？
Sandbox2 は、コンパイルされたものと同じアーキテクチャのみをサンドボックス化できます。
また、Sandbox2 から 32 ビット x86 のサポートが削除されました。64 ビット x86 エグゼキュータを使用して 32 ビット x86 バイナリをサンドボックス化しようとした場合、または 64 ビット x86 バイナリが 32 ビット syscall（int 0x80 経由）を作成しようとした場合、どちらもアーキテクチャ ラベル [X86-32] で識別できるサンドボックス違反が生成されます。
この動作の理由は、syscall 番号がアーキテクチャによって異なるためです。syscall ポリシーはエグゼキュータのアーキテクチャで記述されているため、Sandboxee に別のアーキテクチャを許可するのは危険です。実際、これは一見無害な syscall を許可することにつながる可能性があります。実際には、より有害な別の syscall がサンドボックスをエスケープする可能性があります。
エグゼキュータ プロセスがリクエストできるサンドボックスの数に制限はありますか？
Sandboxee インスタンス（forkserver から生成された新しいプロセス）ごとに新しいスレッドが作成されます。これが制限です。
エグゼキュータは複数のサンドボックスの作成をリクエストできますか？
いいえ。1 対 1 の関係です。エグゼキュータ インスタンスは Sandboxee の PID を保存し、Comms インスタンスを Sandbox インスタンスに管理します。
forkserver.cc 内で「Function not implemented」が表示されるのはなぜですか？
Sandbox2 は、比較的新しいカーネルでのみ実行をサポートしています。現在のカットオフは 3.19 カーネルですが、今後変更される可能性があります。これは、ユーザー名前空間や seccomp（TSYNC フラグ付き）など、比較的新しいカーネル機能を使用しているためです。
本番環境で実行している場合、フリートのほぼすべてが十分に新しいカーネルを実行しているため、問題はありません。ご不明な点がございましたら、お問い合わせください。
Debian または Ubuntu で実行している場合は、次のコマンドを実行するだけでカーネルを更新できます。
sudo apt-get install linux-image-<RECENT_VERSION>