概要

さまざまなシナリオで Sandbox2 を使用する方法とポリシーの作成方法を示すために、いくつかの例を用意しました。

これらの例は //sandboxed_api/sandbox2/examples にあります。詳細については、以下をご覧ください。

CRC4

CRC4 の例は、CRC4 チェックサムの意図的にバグのある計算です。これは、別のプログラムをサンドボックス化する方法と、そのプログラムと通信する方法を示しています。

  • crc4bin.cc: サンドボックス化するプログラム(Sandboxee)
  • crc4sandbox.cc: 実行するサンドボックス プログラム(実行者)。

仕組み:

  1. 実行者は、::sandbox2::GetDataDependencyFilePath() を使用して、ファイルパスから Sandboxee を起動します。
  2. 実行者は、SendBytes() を使用して、通信チャネル Comms 経由で Sandboxee に入力を送信します。
  3. Sandboxee は CRC4 を計算し、RecvUint32() で受信する通信チャネル Comms 経由で実行者に返信を送信します。

プログラムが通信(read()write())以外のシステムコールを行うと、ポリシー違反により強制終了されます。

static

静的の例は、ソースがないサードパーティ バイナリなど、静的にリンクされたバイナリをサンドボックス化する方法を示しています。つまり、サンドボックス化されることを認識していません。

  • static_bin.cc: Sandboxee は、標準入力から ASCII テキストを大文字に変換する静的な C バイナリです。
  • static_sandbox.cc: ポリシーと制限があり、Sandboxee 入力にファイル記述子を使用する実行者。

仕組み:

  1. 実行者は、CRC4 の場合と同様に、GetDataDependencyFilepath を使用して、ファイルパスから Sandboxee を起動します。
  2. 制限を設定し、/proc/version でファイル記述子を開き、MapFd を使用して Sandboxee にマッピングされるようにマークします。
  3. ポリシーでは、一部のシステムコール(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() へのリクエスト(ForkingClient::EnterForkLoop 経由)を受信します。
  • custom_fork_sandbox.cc: カスタム フォークサーバーを起動する実行者。次に、新しい実行者を介してリクエストを送信し、新しい Sandboxee を生成します(fork() を使用)。

ネットワーク

デフォルトで有効になっているネットワーク名前空間により、サンドボックス化されたプロセスが外部に接続できなくなります。この例では、この問題に対処する方法を示します。

接続は実行者内で初期化され、結果のソケットは ::sandbox2::Comms::SendFD() を介して渡されます。Sandboxee は ::sandbox2::Comms::RecvFD() を使用してソケットを受信し、このソケットを使用して通常どおりにデータを交換できます。

  • network_bin.cc: サンドボックス化するプログラム(Sandboxee)。
  • network_sandbox.cc: 実行するサンドボックス プログラム(実行者)。

network_proxy

この例では、ネットワーク名前空間に対処する別の方法を示します。内部的には上記の例とまったく同じように機能しますが、より便利な API として公開されています。

Sandboxee は、次の 2 つの方法でネットワーク接続を確立できます。

  • 自動 : 自動ハンドラをインストールし、定期的に接続呼び出しを発行します。
  • 手動 : NetworkProxyClient を取得し、NetworkProxyClient::Connect を直接使用します。

この例では、両方の方法を示します。connect_with_handler フラグが設定されている場合は自動モードが使用され、それ以外の場合は手動モードが使用されます。

  • network_bin.cc: サンドボックス化するプログラム(Sandboxee)。
  • network_sandbox.cc: 実行するサンドボックス プログラム(実行者)。