サンドボックスとシステムコールフィルタ（seccomp の原理）

サンドボックスとは「やれることを奪う」設計

サンドボックスの目的は、信頼できないコード、あるいは「いつか乗っ取られる」と想定するコードを、それができる操作の集合そのものを狭めた箱に閉じ込めることです。発想を「必要な権限を付与する」ではなく「不要な権限を剥奪する」へ反転させるのが核心で、これは最小権限の原則と多層防御の極端な実装に当たります。

プロセスがカーネルに何かを依頼する唯一の入口はシステムコールです。ファイルを開く、ソケットを張る、他プロセスを覗く、新しいプロセスを起動する——すべて syscall を通ります。逆に言えば、プロセスが発行できる syscall の集合を絞れば、そのプロセスがカーネルへ及ぼせる影響の上限が決まります。Linux の syscall は 300 以上あり、その一つ一つがカーネルコードへの入口、すなわち潜在的な攻撃面です。seccomp（secure computing mode）は、この syscall 面を呼び出し時点で機械的に絞り込む仕組みです。

seccomp の二つのモード

seccomp には歴史的に二つのモードがあります。

STRICT モードは 2005 年に「貸し CPU」用途（信頼できないコードを計算だけさせる）として入りましたが、4 つの syscall しか通らず汎用性がありません。実務で使われるのは 2012 年に追加された FILTER モード（seccomp-bpf） で、開発者が書いた BPF プログラムが各 syscall ごとに判定を下します。以降「seccomp」と言えばこの seccomp-bpf を指します。

フィルタプログラムの入力と出力

seccomp-bpf のフィルタは、cBPF（classic BPF）バイトコードで書かれた小さなプログラムです。各 syscall がカーネルに入る直前にこのプログラムが実行され、入力として seccomp_data 構造体を受け取ります。中身は以下の固定フィールドです。

• nr — システムコール番号（例 __NR_open）。
• arch — 呼び出し元のアーキテクチャ（AUDIT_ARCH_X86_64 など）。
• instruction_pointer — 呼び出し時のプログラムカウンタ。
• args[0..5] — syscall の引数 6 つ（レジスタの生値）。

フィルタはこれらを検査し、32 ビットの戻り値を返します。上位ビットがアクション、下位がデータ（返す errno 値など）です。

複数のフィルタを積み重ねた場合、カーネルは全フィルタを評価し、優先度が最も高い（最も厳しい）アクションを採用します。優先度は高い順に KILL_PROCESS → KILL_THREAD → TRAP → ERRNO → USER_NOTIF → TRACE → LOG → ALLOW で、どれか一つでも KILL を返せば KILL が勝ちます。つまりフィルタは追加で緩めることはできず、積めば積むほど締まる一方向の仕組みです。

許可リスト型フィルタの擬似コード

堅牢なフィルタは許可リスト型で設計します。アプリが実際に使う syscall だけを通し、それ以外はデフォルトで拒否する形です。考え方を擬似コードで示します。

seccomp フィルタの判定（許可リスト型）:

  # 1. まずアーキテクチャを固定する（重要）
  if data.arch != AUDIT_ARCH_X86_64:
      return KILL_PROCESS

  # 2. 既知の危険 syscall を明示的に潰す
  if data.nr in `{ptrace, execve, mount, keyctl, ...}`:
      return KILL_PROCESS

  # 3. 許可リストの syscall を通す
  if data.nr in `{read, write, mmap, futex, exit_group, ...}`:
      return ALLOW

  # 4. 引数まで見て条件付き許可（例：実行可能メモリの禁止）
  if data.nr == mmap and (data.args[2] & PROT_EXEC) != 0:
      return ERRNO(EPERM)

  # 5. 上記いずれにも当たらない未知の syscall は拒否
  return ERRNO(EPERM)

なぜ syscall 入口での検査が強いのか

seccomp の強さは、検査の位置にあります。capability などの権限チェックは「syscall を実行し始めた後、その内部で権限を確認する」ため、チェックに到達するまでにカーネルコードが動きます。一方 seccomp はsyscall がカーネルの本処理に入る前に判定するため、禁止された syscall は対応するカーネルコードに一切到達しません。

これが「攻撃面の縮小」の正確な意味です。あるカーネル関数にバグがあっても、そこへ至る唯一の syscall が seccomp で塞がれていれば、そのバグは**到達不能（unreachable）**になり実質的に無害化されます。コンテナの文脈での seccomp の役割も同じで、共有カーネルという弱点を直接補強します（コンテナ分離の原理（namespace・cgroup・seccomp））。

ロードの不可逆性と前提条件

seccomp フィルタは prctl(PR_SET_SECCOMP, ...) または seccomp(2) システムコールでロードします。重要な性質が二つあります。

第一に、一度ロードしたフィルタは解除できず、fork／clone した子にも execve 後にも継承されます。これにより、サンドボックス化したプロセスが後から自分の制約を緩めて脱出する経路を塞ぎます。Chrome のレンダラは初期化（フォント列挙やライブラリロード）を終えた直後にフィルタをロードし、以後は最小の syscall 集合だけで動きます。

第二に、非特権プロセスがフィルタをロードするには no_new_privs ビットを立てる必要があります。これは「この後 execve しても setuid 等で特権を新たに獲得しない」という約束で、これがないと「制限付きプロセスが setuid バイナリを exec して権限昇格する」抜け道が残ってしまいます。no_new_privs と seccomp は対で機能します。

実装の現実：libseccomp と性能

生の cBPF を手書きするのは煩雑なため、実務では libseccomp ライブラリを使います。seccomp_rule_add() でルールを宣言的に追加し、ライブラリが最適化された BPF プログラムへコンパイルします。Docker のデフォルトプロファイルや systemd の SystemCallFilter= ディレクティブ、OpenSSH の特権分離（privsep）プロセスも、この層の上に構築されています。

性能面では、フィルタは1回の syscall あたり数十ナノ秒程度の追加コストで済みます。BPF プログラムは分岐の線形列で、許可リストが大きいと逐次比較で遅くなるため、libseccomp は番号で二分探索する木構造に展開して定数時間に近づけます。攻撃面を縮小する代償としては十分小さく、これが seccomp が広く常用される理由です。

適用例：Chrome と Firefox

ブラウザは「敵のコードを毎秒実行する」前提の代表格で、seccomp の最も洗練された利用例です（詳細はブラウザサンドボックスとサイト分離の原理）。

• Chrome（Linux） — レンダラ・GPU・ネットワークサービスなど役割ごとにプロセスを分け、攻撃面の広いレンダラを seccomp-bpf で締める。ファイルやネットワークへの特権操作はすべてブローカ（ブラウザプロセス）への IPC に置換し、レンダラ自身は open や connect を呼べない。unprivileged user namespace によるファイルシステム隔離と二重の壁を作る。
• Firefox — 同様にコンテンツプロセスを seccomp で隔離し、ファイル I/O などは IPC でブローカに「seccomp ブローカリング」として委譲する。Windows では AppContainer 等、macOS では Seatbelt（sandbox プロファイル）と、OS ごとに等価な機構を使い分ける。

いずれも狙いは同じです。レンダラのメモリ破壊バグ（メモリ破壊系のエクスプロイト）で攻撃者が任意コード実行を得ても、得られるのは権限を奪われたプロセスの制御にすぎません。端末を掌握するには、許された数少ない syscall や IPC 経由でブローカやカーネルのバグを突くサンドボックス脱出という第二の脆弱性が追加で要り、攻撃チェーンが一段長くなります。

まとめ

seccomp-bpf は、プロセスが発行できるシステムコールを呼び出し入口で許可リスト判定し、到達可能なカーネル攻撃面そのものを物理的に縮小する仕組みです。capability が「root の権利」を、seccomp が「syscall の呼び出し」を絞るという役割分担を区別することが理解の鍵で、禁止された syscall は対応するカーネルコードに一切到達しないため、そこにバグがあっても無害化されます。

フィルタは syscall 番号・引数・アーキを入力に取る BPF プログラムで、許可リスト型で設計し、アーキ固定と no_new_privs を前提に不可逆ロードします。Chrome や Firefox のレンダラ隔離、Docker や systemd のサービス制限など応用は広く、いずれも「乗っ取られても被害を封じる」最小権限の徹底です。ただし seccomp 単体は万能ではなく、capability・名前空間・LSM と重ねる多層防御の一層として位置づけるのが原理的な正解です。