MicrosoftリサーチのブラウザベースOS、コードネームGazelle

作者 Abel Avram , 翻訳者 竹中 翔 - (株)ポータルアイランド 投稿日 2009年7月6日 午後3時0分

コミュニティ

.NET,

Architecture

トピック

セキュリティ

タグ

Browsers,

Microsoft

原文(投稿日：2009/6/30)へのリンク

Helen J. Wang氏率いるMicrosoftリサーチチームは、インターネット利用時の堅固なセキュリティを目的としたブラウザベースOS、Gazelle (PDF)を作成した。

GazelleはWindowsライクな新しいオペレーティングシステムではなく、マルチプリンシパルオペレーティングシステムとして動作するカーネルを持った、新しいタイプのブラウザである。このカーネルが、リソース保護と様々なWebサイトプリンシパル間のリソース共有を担当する。セキュリティプリンシパルとは、“コンピュータシステムやネットワークによって認証可能なものであり、認証はこのようなものの身元（アイデンティティ）を検証・確認する処理”である。MicrosoftリサーチチームのメンバーであるJanie Chang氏は、ブラウザプリンシパルが何であるか定義し、なぜセキュリティの問題に適しているかを説明している。

ブラウザ界の用語では、一般的にプリンシパルはWebサイトと同一です。一般的にPC上に一人のユーザが存在する時、リソースの共有とは実質的には異なる起源からアプリケーションにアクセスすることです。Webページの場合、各ページは異なるプリンシパルのコンテンツで構成され、各々がコンピュータリソースの共有を行います。従って、ブラウザがプリンシパルとリソース要求を管理するアプリケーションプラットフォームであるというのは自然なことです。

Webページは他のWebプリンシパルの広告やニュースフィードのようなコンテンツを提供するでしょう。ブラウザは未だ、これらの全てのプリンシパルを同じプロセスや保護ドメイン内に共存させます。広告が悪意のあるコードや出来の悪いコードを含んでいれば、ネットワークを占有したり、パフォーマンスを悪化させたり、ページ全体をフリーズさせたり、或いはブラウザをクラッシュさせたりしてしまいます。ブラウザオペレーティングシステムでは、“不良”プリンシパルが他のプリンシパルやブラウザ、ホストマシンに影響を与えることはできません。

Wang氏らはWebサイトとしてのプリンシパルを、“Webサイトの起源（プロトコル、ドメイン名、ポート）によってラベリングされたサイトオリジンポリシー(SOP)”であると定義する。プリンシパル保護を強制するため、プリンシパルとオペレーティングシステムの間にブラウザカーネルが取り入れられる(図１)。

ブラウザカーネルは分離された保護ドメイン内で動作しており、ブラウザプリンシパルと従来のOSの間のやり取りに介入します。そして、プリンシパルがシステムリソースにアクセスするのを仲介し、ブラウザのセキュリティポリシーを強制するのです。本質的に、ブラウザカーネルはブラウザプリンシパルに対してオペレーティングシステムとして機能し、システムリソースの保護と共有を行います。また、アドレスバーやメニューの管理も行います。ブラウザカーネルはマウスクリックやキータイプのようなユーザイベントを含む、下層のオペレーティングシステムによって発生したイベントを全て受け取り、それらを適切なプリンシパルインスタンスに処理させます。ユーザが異なる起源のURLを指しているハイパーリンクをクリックした場合、ブラウザカーネルは対象ページをレンダリングするために、そのURLのプリンシパルインスタンス用の保護ドメインを(もしまだ存在しなければ)生成し、リンク元ページの保護ドメインは破棄します。さらに、URLのプリンシパルインスタンスのためにウィンドウの再割り当てと再初期化を行います。

Wang氏らはGazelleの実装とGoogle Chromeの現在のセキュリティ方策を比較した。Google Chromeはモノリシックプロセス、ブラウジングインスタンス毎プロセス、サイトインスタンス毎プロセス、サイト毎プロセスのようなプロセスモデルを採用している。ブラウザインスタンスは相互連結されたウィンドウ、フレーム、サブフレームで構成される。一方、サイトインスタンスは同一サイトを起源とし、ブラウジングインスタンス内に存在しているページのコレクションである。サイトは“レジストリ管理されたドメイン名を共有するSOP起源のセット”として定義される。例えば、attackerAd.socialnet.com、alice.profiles.socialnet.com、socialnet.comは同じレジストリ管理されたドメイン名socialnet.comを共有する。これらはChromeによって同じサイト、もしくは同じプリンシパルであるとみなされる。Wang氏らによれば

Chromeはデフォルトでサイトインスタンス毎プロセスモデルを使用します。さらに、… Chromeの現在の実装ではサイトインスタンス毎プロセスモデルやサイト毎プロセスモデルでの完全なサイトの隔離をサポートしません。親ページと異なる起源をソースとするネストされたiframeのような埋め込みプリンシパルは、親ページと同じプロセス内に配置されます。Chromeのモノリシックとブラウジングインスタンス毎プロセスモデルは、モノリシックプロセスやブラウザインスタンス内でのメモリやその他のリソース保護を提供しません。サイト毎プロセスモデルはサイトインスタンスへの障害抑制アクセスを提供しません。Chromeのサイトインスタンス毎モデルがGazelleのプリンシパル・インスタンス毎２プロセスモデルに最も近いモデルですが、極めて重要な違いがいくつかあります。(1) Chromeのプリンシパルはサイトですが（上記参照）、GazelleのプリンシパルはSOPプリンシパルと同じです。(2) Chromeでは同じプロセス内にWebサイトプリンシパルと埋め込みプリンシパルが共存しますが、Gazelleではそれらは分離された保護ドメインに配置されます。このデザインの追及はクロスプリンシパル表示保護を含む新しい研究課題を我々にもたらしました。(3) Chromeでは異なるプリンシパルや異なるサイトのプラグインはプラグインプロセスを共有しますが、Gazelleでは分離された保護ドメインに配置されます。(4) Chromeは同一プロセス内に共存しているプリンシパルにサイトオリジンポリシーを強制するため、レンダリングプロセスに頼っています。これらの違いは、Chromeではクロスプリンシパル（もしくはクロスサイト）保護がブラウザカーネルに加えて、レンダリングプロセスとプラグインプロセスで生じるのに対し、GazelleのブラウザカーネルはOSとして機能し、表示を含む全てのリソースのクロスプリンシパル保護を行うということを意味しています。

GazelleとIE 8を比較し、Wang氏らはこのようなことに気がついた。

IE 8はタブ同士を分離するためにOSプロセスを使用します。ユーザが互いに信頼できない複数のサイトを一つのタブ内でブラウジングしたり、Webページが(例えば広告のような)信頼できないサイトのコンテンツをiframeでホストしている可能性があるので、この粒度では不十分です。

リサーチチームの総体的な結論は

基本的に、Chrome、IE 8とGazelleとは目指しているゴールが違います。これらはセキュリティよりもユーザのブラウジングセッションの障害抑制アクセスのためにマルチプロセスを使用しています。これらのセキュリティ上のゴールは、ブラウザやWebからホストマシンを保護することです。これはプロセスのサンドボックス化によって達成されます。ChromeとIE 8はブラウザアーキテクチャ設計の進化により優れたマイルストーンを達成しました。将来、Webにより多くのデータや機能を持たせ、ブラウザを有力なアプリケーションプラットフォームとして位置付ける際に、ブラウザをオペレーティングシステムとしてとらえ、ホストマシンに加えてWebサイトプリンシパル同士を保護することは、ブラウザの設計者にとって重大です。これがGazelleのゴールです。

GazelleのプロトタイプはIE 7がベースになっており、後方互換パース処理、DOM管理、JavaScriptエンジンを利用している。ブラウザのパフォーマンスはIE 8やGoogle Chromeと同程度と報告されている。クロスオリジンスクリプトソース保護は図２に示されているアーキテクチャによって解決されている。その考え方は悪意のある動作やエラーを発生させるコードを隔離するため、プラグインコードをサンドボックス化することである。

このリサーチプロジェクトは、ブラウザを完全にオペレーティングシステムに組み込む計画を停止していないMicrosoftを驚かせた。このような動きは多くの企業にとって確実に大きな衝撃になるだろう。なぜなら、ブラウザは支配的なデスクトップアプリケーションになりつつある。Microsoftは、これは自分たちの真意ではないがブラウジングのセキュリティを向上させる、と断言している。現在、Gazelleはリサーチプロジェクトだが、時間がたてば製品か、少なくともIEや、他のブラウザやWindows上で動くオンラインアプリケーションのために残されている部分に組み込まれる形で我々の前に姿を現すだろう。

• 次へ >