Mozilla HacksのIntroducing Firefox’s new Site Isolation Security Architectureを読みました。FirefoxのProject Fission、つまりSite Isolationがなぜ必要になったのかを、Spectre以後のブラウザ防御として説明している記事です。
Webには昔から同一オリジンポリシーがあります。これは、あるオリジンの文書やスクリプトが、別オリジンのリソースへどう触れるかを制限する重要な仕組みです。ただしSpectreのようなCPUレベルのサイドチャネル攻撃では、アプリケーション層の境界だけでは足りない可能性が見えてきました。そこでFirefoxは、サイトごとにOSプロセスを分け、メモリ空間そのものを分離する方向へ進みました。
記事の要点
- Site Isolationは、異なるサイト由来のWebコンテンツを別々のOSプロセスに分けるFirefoxのセキュリティアーキテクチャです。
- 背景には、MeltdownやSpectreのように、同じプロセス内のメモリを推測的実行やタイミング差から読み取る攻撃への対策があります。
- 従来のマルチプロセス構成では、複数サイトが同じcontent processに入る可能性がありました。Site Isolationでは、トップレベルページだけでなく、別サイトのサブフレームも別プロセスに分けます。
- 同じサイトかどうかの判定には、GitHub PagesやBlogspotのような共有ドメインを扱うためにPublic Suffix Listも関係します。
- 副次的な効果として、重い処理やクラッシュの影響を別サイトへ波及させにくくし、CPUコアの活用にもつながります。
参照リンクから見えたこと
MDNの同一オリジンポリシーの記事を見ると、オリジンはプロトコル、ホスト、ポートの組み合わせで決まります。この仕組みは今でもWebセキュリティの土台ですが、Site Isolationの記事が扱っているのは、その上に「プロセスの境界」を足す話です。JavaScriptの権限モデルだけでなく、OSのメモリ分離を使って防御する発想です。
Mozilla Security Blogのタイミング攻撃への緩和策も確認しました。Firefoxは当時、performance.now()の精度低下やSharedArrayBufferの無効化など、短期的な緩和策を入れています。Site Isolationは、こうした一時的な緩和から、より構造的な防御へ進む流れにあります。
また、Project Fissionは単なる設定項目ではなく、Firefoxのプロセスモデルを作り替える大規模な取り組みでした。この記事の後に続くWin32k LockdownやRLBoxの記事まで見ると、Firefoxは「サイト単位」「OS権限」「ライブラリ単位」という複数の粒度で隔離を積み重ねていることが分かります。
気づき
今回の気づきは、Site Isolationが同一オリジンポリシーの置き換えではなく、別レイヤーの補強だという点です。同一オリジンポリシーは「触ってよいか」を決めるルールですが、Site Isolationは「そもそも同じメモリ空間に置かない」ための構造です。ブラウザの防御は、ルールだけでなく配置そのものを変える段階に入っていたのだと感じました。
コメントを残す