例
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
概要
さまざまなシナリオで Sandbox2 を使用する方法とポリシーの作成方法を示すために、いくつかの例を用意しました。
これらは //sandboxed_api/sandbox2/examples にあります。詳細については、以下をご覧ください。
CRC4
CRC4 の例は、CRC4 チェックサムの意図的にバグのある計算です。これは、別のプログラムをサンドボックス化して、そのプログラムと通信する方法を示しています。
仕組み:
- エグゼキュータは、
::sandbox2::GetDataDependencyFilePath()
を使用してファイルパスから Sandboxee を起動します。
- エグゼキュータは、
SendBytes()
を使用して、通信チャネル Comms
を介して Sandboxee に入力を送信します。
- Sandboxee は CRC4 を計算し、通信チャネル
Comms
を介してエグゼキュータに返信を送信します。エグゼキュータは RecvUint32()
で返信を受信します。
プログラムが通信(read()
と write()
)以外のシステムコールを行うと、ポリシー違反により強制終了されます。
static
静的サンプルは、ソースのないサードパーティ バイナリなど、静的にリンクされたバイナリをサンドボックス化する方法を示しています。つまり、サンドボックス化されることを認識していません。
仕組み:
- 実行プログラムは、CRC4 の場合と同様に、
GetDataDependencyFilepath
を使用してファイルパスから Sandboxee を起動します。
- 制限を設定し、
/proc/version
でファイル記述子を開き、MapFd
を使用して Sandboxee でマッピングされるようにマークします。
- このポリシーでは、一部の syscall(
open
)がポリシー違反により強制終了されるのではなく、エラー(ENOENT
)を返すことが許可されます。これは、どのシステムコールが行われるかを変更できないサードパーティ プログラムをサンドボックス化する場合に便利です。代わりに、システムコールを正常に失敗させることができます。
このツール例は、独自のポリシーを開発して Sandbox2 API を試すためのツールであると同時に、その機能のデモでもあります。
- sandbox2tool.cc: 次の処理を示す実行ツール:
- 別のバイナリをサンドボックス化して実行する方法、
- ファイル システム チェックの設定方法
- 実行プログラムが Sandboxee を非同期で実行して、出力を段階的に読み取る方法。
実際に試してみる:
Bazel
bazel run //sandboxed_api/sandbox2/examples/tool:sandbox2tool -- \
--sandbox2tool_resolve_and_add_libraries \
--sandbox2tool_additional_bind_mounts /etc \
/bin/cat /etc/hostname
CMake + Ninja
cd build-dir
ninja sandbox2_sandbox2tool && \
./sandbox2_sandbox2tool \
--sandbox2tool_resolve_and_add_libraries \
--sandbox2tool_additional_bind_mounts /etc \
/bin/cat /etc/hostname
Google3(Blaze)
blaze run //third_party/sandboxed_api/sandbox2/examples/tool:sandbox2tool -- \
--sandbox2tool_resolve_and_add_libraries \
--sandbox2tool_additional_bind_mounts /etc \
/bin/cat /etc/hostname
フラグ:
--sandbox2tool_resolve_and_add_libraries
: Sandboxee に必要なライブラリを解決してマウントする
--sandbox2tool_additional_bind_mounts <PATHS>
を使用して、Sandboxee で追加のディレクトリを使用できるようにします。
--sandbox2tool_keep_env
(現在の環境変数を維持するために使用します)
--sandbox2tool_redirect_fd1
を使用して Sandboxee STDOUT_FILENO (1)
を受け取り、ローカルに出力します。
--sandbox2tool_cpu_timeout
: CPU タイムアウトを秒単位で設定します。
--sandbox2tool_walltime_timeout
: 壁時計のタイムアウトを秒単位で設定します
--sandbox2tool_file_size_creation_limit
: 作成されるファイルの最大サイズを設定します
--sandbox2tool_cwd
: サンドボックスの現在の作業ディレクトリを設定します。
custom_fork
custom_fork
の例は、バイナリを初期化するサンドボックスを作成し、親エグゼキュータからの fork()
リクエストを待機する方法を示しています。
このモードでは、他のタイプのサンドボックスと比較してパフォーマンスが向上する可能性があります。このモードでは、Sandboxee の新しいインスタンスを作成する際に、新しいバイナリを実行する必要がなく、既存のバイナリをフォークするだけで済むためです。
- custom_fork_bin.cc: 新しい Sandboxee を生成するために
fork()
へのリクエスト(Client::WaitAndFork
経由)を受信するカスタム fork サーバー。
- custom_fork_sandbox.cc: カスタム フォーク サーバーを起動する実行ファイル。次に、新しい Sandboxee を生成(
fork()
経由)するリクエストを(新しい実行プログラム経由で)送信します。
ネットワーク
ネットワーク Namespace はデフォルトで有効になっており、サンドボックス化されたプロセスが外部に接続できないようにします。この例では、この問題に対処する方法を示します。
接続はエグゼキュータ内で初期化され、結果のソケットは ::sandbox2::Comms::SendFD()
を介して渡されます。Sandboxee は ::sandbox2::Comms::RecvFD()
を使用してソケットを受け取り、このソケットを使用して通常どおりデータを交換できます。
network_proxy
この例では、ネットワーク Namespace を処理する別の方法を示します。内部的には上記の例とまったく同じように動作しますが、より便利な API として公開されています。
Sandboxee は、次の 2 つの方法でネットワーク接続を確立できます。
- 自動 - 自動ハンドラをインストールし、定期的に接続呼び出しを発行します。
- manual -
NetworkProxyClient
を取得し、NetworkProxyClient::Connect
を直接使用します。
この例では、両方の方法を示します。connect_with_handler
フラグが設定されている場合は自動モードが使用され、それ以外の場合は手動モードが使用されます。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-26 UTC。"],[[["\u003cp\u003eSandbox2 provides examples demonstrating how to sandbox programs in different scenarios and write policies to control their behavior.\u003c/p\u003e\n"],["\u003cp\u003eExamples include sandboxing static binaries, networking scenarios, custom fork servers, and a comprehensive tool for policy development and experimentation.\u003c/p\u003e\n"],["\u003cp\u003eSandboxees can communicate with the executor through communication channels, and policies can be defined to allow or deny specific syscalls.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003esandbox2tool\u003c/code\u003e example provides a versatile interface for running sandboxed binaries, setting up filesystem checks, and managing resources.\u003c/p\u003e\n"],["\u003cp\u003eSandbox2 enables network communication within sandboxed environments through socket passing and dedicated proxy mechanisms.\u003c/p\u003e\n"]]],[],null,["Overview\n\nWe have prepared a few examples to demonstrate how to use Sandbox2 in different scenarios and how to write policies.\n\nYou can find them in [//sandboxed_api/sandbox2/examples](https://github.com/google/sandboxed-api/blob/master/sandboxed_api/sandbox2/examples), see below for detailed explanations.\n\nCRC4\n\nThe CRC4 example is an intentionally buggy calculation of a CRC4 checksum, which demonstrates how to sandbox another program and how to communicate with it.\n\n- [crc4bin.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/crc4/crc4bin.cc): The program we want to sandbox (i.e. the Sandboxee)\n- [crc4sandbox.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/crc4/crc4sandbox.cc): The sandbox program that will run it (i.e. the executor).\n\nHow it works:\n\n1. The executor starts the Sandboxee from its file path using `::sandbox2::GetDataDependencyFilePath()`.\n2. The executor sends input to the Sandboxee over the communication channel `Comms` using `SendBytes()`.\n3. The Sandboxee calculates the CRC4 and sends its replies back to the executor over the communication channel `Comms` which receives it with `RecvUint32()`.\n\nIf the program makes any syscall other than communicating (`read()` and `write()`), it is killed due to a policy violation.\n\nstatic\n\nThe static example demonstrates how to sandbox a statically linked binary, such as a third-party binary for which you do not have the source, meaning it is not aware that it will be sandboxed.\n\n- [static_bin.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/static/static_bin.cc): The Sandboxee is a static C binary that converts ASCII text from standard input to uppercase.\n- [static_sandbox.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/static/static_sandbox.cc): The executor with its policy, limits, and using a file descriptor for Sandboxee input.\n\nHow it works:\n\n1. The executor starts the Sandboxee from its file path using `GetDataDependencyFilepath`, just like for CRC4.\n2. It sets up limits, opens a file descriptor on `/proc/version`, and marks it to be mapped in the Sandboxee with `MapFd`.\n3. The policy allows some syscalls (`open`) to return an error (`ENOENT`) rather than being killed due to a policy violation. This can be useful when sandboxing a third-party program where we cannot modify which syscalls are made, so instead we can make them fail gracefully.\n\ntool\n\nThe tool example is both a tool to develop your own policies and experiment with Sandbox2 APIs, as well as a demonstration of its features.\n\n- [sandbox2tool.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/tool/sandbox2tool.cc): The executor demonstrating:\n - how to run another binary sandboxed,\n - how to set up filesystem checks, and\n - how the executor can run the Sandboxee asynchronously to read its output progressively.\n\nTry it yourself: \n\nBazel \n\n bazel run //sandboxed_api/sandbox2/examples/tool:sandbox2tool -- \\\n --sandbox2tool_resolve_and_add_libraries \\\n --sandbox2tool_additional_bind_mounts /etc \\\n /bin/cat /etc/hostname\n\nCMake + Ninja \n\n cd build-dir\n ninja sandbox2_sandbox2tool && \\\n ./sandbox2_sandbox2tool \\\n --sandbox2tool_resolve_and_add_libraries \\\n --sandbox2tool_additional_bind_mounts /etc \\\n /bin/cat /etc/hostname\n\nGoogle3 (Blaze) \n\n blaze run //third_party/sandboxed_api/sandbox2/examples/tool:sandbox2tool -- \\\n --sandbox2tool_resolve_and_add_libraries \\\n --sandbox2tool_additional_bind_mounts /etc \\\n /bin/cat /etc/hostname\n\nFlags:\n\n- `--sandbox2tool_resolve_and_add_libraries` to resolve and mount the required libraries for the Sandboxee\n- `--sandbox2tool_additional_bind_mounts \u003cPATHS\u003e` to make additional directories available to the Sandboxee\n- `--sandbox2tool_keep_env` to keep current environment variables\n- `--sandbox2tool_redirect_fd1` to receive the Sandboxee `STDOUT_FILENO (1)` and output it locally\n- `--sandbox2tool_cpu_timeout` to set CPU timeout in seconds\n- `--sandbox2tool_walltime_timeout` to set wall-time timeout in seconds\n- `--sandbox2tool_file_size_creation_limit` to set the maximum size of created files\n- `--sandbox2tool_cwd` to set the sandbox's current working directory\n\ncustom_fork\n\nThe `custom_fork` example demonstrates how to create a sandbox which will initialize the binary, and then wait for `fork()` requests coming from the parent executor.\n\nThis mode offers potentially increased performance with regard to other types of sandboxing, as here, creating new instances of Sandboxees doesn't require executing new binaries, just forking the existing ones\n\n- [custom_fork_bin.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/custom_fork/custom_fork_bin.cc): The custom fork-server, receiving requests to `fork()` (via `Client::WaitAndFork`) in order to spawn new Sandboxees.\n- [custom_fork_sandbox.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/custom_fork/custom_fork_sandbox.cc): The executor, which starts a custom fork server. Then it sends requests to it (via new executors) to spawn (via `fork()`) new Sandboxees.\n\nnetwork\n\nThe network namespace, which is enabled by default, prevents the sandboxed process from connecting to the outside world. This example demonstrates how to deal with this problem.\n\nA connection is initialized inside the executor and the resulting socket is passed via `::sandbox2::Comms::SendFD()`. The Sandboxee receives the socket by using `::sandbox2::Comms::RecvFD()` and then it can use this socket to exchange the data as usual.\n\n- [network_bin.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/network/network_bin.cc): The program we want to sandbox (i.e. the Sandboxee).\n- [network_sandbox.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/network/network_sandbox.cc): The sandbox program that will run it (i.e. the executor).\n\nnetwork_proxy\n\nThis example demonstrates an alternative way of dealing with a network namespace. Internally, it works in exactly the same way as the above example, but is exposed as a more convenient API.\n\nThe Sandboxee can establish a network connection in 2 different ways:\n\n- **automatic** -- By installing an automatic handler and then issuing regular connect calls.\n- **manual** -- By obtaining a `NetworkProxyClient` and directly using `NetworkProxyClient::Connect`.\n\nThis example shows both methods. Automatic mode is used when the `connect_with_handler` flag is set, otherwise manual mode is used.\n\n- [network_bin.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/network_proxy/networkproxy_bin.cc): The program we want to sandbox (i.e. the Sandboxee).\n- [network_sandbox.cc](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/network_proxy/networkproxy_sandbox.cc): The sandbox program that will run it (the executor)."]]