The Multi-Principal OS Construction of the Gazelle Web Browser, Usenix Security 2009

WebSecurity

Wang, H. J.; Grier, C.; Moshchuk, A.; King, S. T.; Choudhury, P. & Venter, H, The Multi-Principal OS Construction of the Gazelle Web Browser, pp.417-432, Usenix Security Symposium 2009.

Microsoftの Helen Wang らによって最近発表された、新しい、安全なブラウザのアーキテクチャの提案。
Webブラウザにロードされるコンテンツの主体 (principle) ごとに細かい単位でOSのプロセスに分離して実行される。また、既存のコンテンツとの互換性を大事にしていて、テストした20のWeb appのうち、19は動いた。

セキュリティモデル

  • Same Origin Policy (SOP)がベース。
  • ただし、<iframe>だけでなく、<object>, <embed>, <img>, ある種の <input> は、それぞれにロードされたコンテンツのオリジン単位の主体となる。つまり、SOPが plug-inのコンテンツにまで適用される。

アーキテクチャ

  • 主体 (principle) の単位で、別のOSプロセスに分離される (principle instance)。プロセスとOSの間にBrowser Kernelがいて、全体をマネージする。
  • principleの判別方法は、基本的に same-origin policyと同じで、{プロトコル、サーバ、ポート} の組で判定される。
    • 別のTabで同じURLにアクセスしても、別の principleになる
    • ただし、あるページの中のIFRAMEが親ページと同じドメインなら、デフォルトで同じ principleになる。ただし、親ページ側で制限をかけることも可能
  • Browser Kenelの仕事は
    • principle instance (プロセス) のOSリソースへのアクセスを仲介
    • ブラウザクロームの管理
    • OSからあがってきたユーザイベント（キーボード、マウスイベントなど）を principle instance にディスパッチ
    • 新しいURLにナビゲートしたときに、そのURL のための保護ドメインを作って principle instance を立ち上げたり、ブラウジングが終わったら保護ドメインを破棄したり
  • 画面描画に関しては、
    • principle instanceがコンテンツをレンダリングして bitmap にするところまで責任がある。ブラウザカーネルがbitmapをうけとって、画面のどの部分にどう描画するかを決める。
    • ページ内にフレームなどが含まれる場合、ページの principle instanceが 大家（地主）、フレームの principleが店子、になる。大家と店子の間で互いのコンテンツを干渉しないように、細かいアクセス制御が行われる。たとえば
      • 店子フレームの場所は大家しかRWできない
      • 店子フレームのサイズは大家がRW、店子は自分のサイズをRできる
      • 店子フレーム内に表示している情報は店子しか見られない
      • 店子フレームのURLは、大家はWのみ、店子はR/W可能


既存のブラウザとの違い

  • Chromeとの違い
    • Chrome では主体はサイトのドメイン名（サーバ名を含まない）だが、Gazelleでは Same-origin Policy (SOP)と同じ（サーバ名を含む）
    • ChromeではWebサイトの主体と組み込まれた主体は同じプロセス上に共存、Gazelleでは別の保護ドメインに分離
    • Chromeでは異なるサイトのプラグインのコンテンツが同じプロセス上に共存するが、Gazelleでは別の保護ドメインに分離
    • Chromeではレンダリングエンジンが複数主体の間でSOPを強制するが、Gazelleではレンダリングエンジンへの依存なし
  • IE8との違い
    • IE8ではブラウザのタブごとに別のプロセスとして動作するが、タブの中にIFRAMEがある場合などには同じプロセス内で表示されることになる
  • OP Browser[2] との違い
    • OP BrowserではHTML engine, javascript などが別のプロセスとして分離される
    • そのため、コンポーネント間のIPCのコストが高い
    • 各コンポーネントはWebページをレンダリングする際に運命を共にするようになってるので、ひとつがコケると殆どのページが表示されない
    • OSレベルの cross-principleな保護はできない
  • Tahoma[11]との違いは、TahomaではWeb applicationごとにVMで分離するが、Web applicationの区切りはmanifestファイルで決めるので、既存のブラウザの principleごと（SOPということ？）の保護はできない