ブラウザサンドボックスとサイト分離の原理

なぜブラウザは「敵のコードを実行する前提」で設計されるのか

ブラウザは特異なソフトウェアです。ユーザーがアクセスするだけで、見知らぬサーバーから届いた HTML・CSS・JavaScript・画像・フォント・WebAssembly を毎秒のように実行します。これらは事実上「信頼できない入力」であり、パーサや JIT コンパイラには毎年のように脆弱性が見つかります。前提を「いつかレンダラは乗っ取られる」と置き、乗っ取られても被害を封じ込める多層防御を敷くのが現代ブラウザの設計思想です。中核がプロセス分離とサンドボックス、そして**サイト分離（Site Isolation）**です。

レンダラの権限剥奪：何もできないプロセスにする

サンドボックスの本質は「やれることを足す」ではなく**「やれることを奪う」**ことです。レンダラは起動直後の初期化（フォントの列挙やライブラリのロード）を終えた瞬間に、自らの権限を能動的に絞り込みます。これを sandbox lockdown と呼びます。剥奪後のレンダラは、ファイルを開けず、任意のネットワーク接続を張れず、他プロセスを生成できず、新しい実行可能メモリを勝手に確保することも制限されます。

ではページの表示に必要な操作（ネットワークから次のリソースを取る、Cookie を読む、ファイルをダウンロードする）はどうするのか。すべてブローカへの IPC 依頼に置き換わります。レンダラは「この URL を取得したい」「この origin の Cookie が欲しい」とメッセージを送り、ブローカがポリシーを照合してから代行する。ここでブローカが行うチェックこそが Same-Origin Policy や Cookie のセキュリティモデルの最終的な強制点です。レンダラ内の JS がいくら細工をしても、境界の判断はレンダラの外で下されます。

[レンダラ：権限ゼロ]                 [ブローカ：唯一の特権]
  fetch("https://api.example/x")
     │  IPC: "URLLoaderに取得依頼"
     ▼
   ── メッセージ ──────────────▶  origin/CSP/Cookie ポリシー検査
                                   許可なら実際にソケットを開く
     ◀─ レスポンスのバイト列だけ返す ─┘

この設計の含意は重要です。レンダラのメモリ破壊バグ（メモリ破壊系のエクスプロイト）で攻撃者が任意コードを得ても、得られるのは権限を奪われたプロセスの制御にすぎない。端末を本当に掌握するには、さらにサンドボックスを脱出する第二の脆弱性（ブローカや OS カーネルのバグ）が要る。攻撃の難度が一段跳ね上がります。

OS サンドボックス機構：境界を OS に強制させる

権限剥奪を「お願い」で終わらせず、OS のメカニズムで強制するのがサンドボックスの肝です。プラットフォームごとに使う機構が違います。

Linux：seccomp-bpf。 seccomp（secure computing）モードは、プロセスが発行できるシステムコールを許可リストで絞る仕組みです。seccomp-bpf では、システムコール番号と引数を BPF プログラムで検査し、許可・拒否（SIGSYS で kill、または EPERM 返却）を決めます。レンダラはカーネルとの接点であるシステムコール自体を狭めるため、たとえコード実行を奪われても open connect ptrace clone といった危険な呼び出しがそもそも通らない。Chromium はこれに加え、unprivileged user namespace を使った namespace サンドボックスでファイルシステムや PID 空間を隔離し、二重の壁を作ります。

seccomp-bpf フィルタの考え方（擬似コード）:
  allow_syscalls = `{read, write, mmap(PROT_EXEC無し), futex, ...}`
  if syscall in allow_syscalls and 引数が条件を満たす:
      ALLOW
  elif syscall in `{open, connect, execve, ptrace, ...}`:
      KILL_PROCESS   // 即座に SIGSYS で終了
  else:
      ERRNO(EPERM)

Windows：AppContainer と低 integrity。 Windows は複数の機構を重ねます。古くからの integrity level（プロセスに付くラベル）でレンダラを Low 以下に落とし、より高い integrity のオブジェクトへの書き込みを禁じる。さらに restricted token で SID を無効化し、job object で子プロセス生成やハンドル操作を縛る。近年の主力が AppContainer で、プロセスに専用の SID を与え、明示的に capability を付与されたリソース以外へのアクセスを既定で全拒否します。発想は seccomp と同じ「許可リスト型」で、OS のアクセス制御リスト（ACL）評価のレベルで境界が効きます。

Site Isolation：プロセス境界を信頼境界に昇格させる

ここまでは「レンダラと OS のあいだ」の壁でした。Site Isolation が守るのはサイト同士のあいだの壁です。導入の直接の引き金が Spectre でした。

問題はこうです。従来のブラウザは効率のため、複数のサイトの文書を同一のレンダラプロセスに同居させることがありました。Same-Origin Policy は JS のセマンティクス上のアクセスを禁じますが、Spectre 系の攻撃は投機的実行の副作用としてプロセスのアドレス空間内の任意バイトを読み出すため、論理的な禁止を飛び越えます。つまり攻撃サイトの JS が、同居する別サイトの Cookie やパスワードを同じプロセスのメモリから盗める。これは サイドチャネル攻撃であり、ソフトのアクセスチェックでは原理的に塞げません。

Site Isolation の答えは単純かつ強力です。「異なるサイトは異なるプロセスに置く」。Spectre でメモリを読めても、読めるのは自プロセス内だけ。他サイトの秘密がそもそも同じアドレス空間に存在しないなら、漏れようがない。プロセス境界（OS が保証する仮想アドレス空間の分離）を、Web の信頼境界として再利用するわけです。

実装の難所は、1つのタブが複数サイトを含むクロスサイト iframe です。Site Isolation はこれを out-of-process iframe（OOPIF） として扱い、親フレームと別プロセスでレンダリングしつつ、合成（コンポジット）で1枚の画面に見せます。さらに Spectre が「投機実行で読めてしまうデータ」を減らすため、Cross-Origin Read Blocking（CORB）／ORB がクロスサイトで取得した JSON や HTML をレンダラに渡す前にブローカ側で遮断します。データがレンダラのメモリに載らなければ、投機実行でも読めません。攻撃面を「アクセスチェック」から「データの物理的不在」へ移すのが核心です。

多層防御としての全体像

これら三層は独立ではなく入れ子の信頼境界を成します。最内に JS の論理的境界（Same-Origin Policy）、その外にプロセスとサンドボックス（seccomp/AppContainer）の境界、最外に OS のプロセス分離（Site Isolation が利用）。ある層が破られても次の層が残る設計です。Spectre のように一層を原理的に貫通する攻撃が現れたとき、より外側の物理境界に守りを移せたのは、この層構造があったからです。