Mozilla のためのコンポーネントセキュリティ
ハッカーは、自分たちで無くベーンダーが、とても多くの製品に広がる大きく開いた穴に対して 責任がある、と指摘する。会社ができるだけ早くソフトウェアを公開するために、 店の棚に殺到する中で適切なセキュリティーがしばしば埋没する。 「複雑さが増すにしたがい、脆弱性の機会も増す。」、と 戦略的ビジネスアプリケーションを分析しているハーウィッツグループの副社長 Steven Foote 氏は言う。 -- U.S. News, ハッカーを止められるのか?
セキュリティモデル
Mozilla は、ウェブコンテンツに載っている JavaScript に対する現在のセキュリティモデル (JavaScript Security in Communicator 4.x 参照) を、署名付きスクリプト という例外がありうるのを除いてサポートすべきだ。 Java や JavaScript を使ってウェブコンテンツからアクセスできる 新しい API を、 すべてセキュリティーについてよく検査するべきだ。Communicator 4.X (あるいは Mozilla classic) と違って、Mozilla はブラウザ自体を組み立てるのに 大量にウェブスタイルのプログラミングを使っている。これは、強力な処理を JavaScript が行えるようにするために成し遂げられ、そのため Mozilla に対するセキュリティーモデルが、 二種類のコードをサポートするようにならなければならないという事である。 すなわち信頼できないウェブコンテンツと、信頼できるブラウザ実装コードである。
最終的には Java が Java2 で到達したような、 完全な能力を持ったシステムが必要だ。だが、早くソフトを出す必要があるので、 私たちはもっと単純なバイナリ信託システムを実装しなければならない。 ブラウザ実装に使われるコードはすべて完全な権限を与えられるべきだが、 同時にオフネットからのどんなコードの権限も、 4.X の時と同様に制限されるべきだ。
私は、ウェブベースのコードができる事に、次のような制限を加える事を 提案している:
- ウェブベースの XUL 禁止
- RDF への直接アクセス禁止
- Chrome はローカルファイルシステムのみから実行する。(すなはち、ダウンロード可能な chrome 禁止で インストール可能な chrome のみ)
- 限られた XPConnect コンポーネントへのアクセス--ほとんどのコンポーネントはウェブコンテンツから アクセス不可能とするつもりで、アクセス可能なものはセキュリティ検査を受けなければならない。
- ウェブコンテンツからまわりを囲む chrome へのアクセス禁止
実装
コード形式の識別
私たちのセキュリティモデルには二つの形式のコードがある: つまりウェブコンテンツと ブラウザ実装コードだ。この二つをどうやって識別しようか?現在の JavaScript コードベースは、主体 (principal) を評価される全スクリプトと関連付ける機能のサポートが入ってる。 そして実行中、実行している JavaScript のスタックフレームと対応した主体のスタックを、 検索できる。従って、いかなる点でも、極めてセキュリティ上危険なコードは、 スクリプトによって呼び出されたのなら、そうならば、 そのスクリプトが権限を持っているかに関わらず、調べられる。コンポーネントセキュリティの分析
DOM
DOM は 4.X からのセキュリティモデルを実装すべきだ (少なくとも署名のない部分は)。 歴史的には、DOM はほとんどの公然の悪用がある領域を抱えていた。 だからここのセキュリティの実装には注意深く検査する必要がある。ここにいくつか 4.X の DOM セキュリティモデルへ追加する提案がある。 Bell 研究所からの研究者たちがいくつか新しい特徴を提案してきた。もっとも著しいのは ドメイン固有のポリシーだ。Bugzilla bug 858 に似た提案が説明され、念入りに仕上げられている。
XUL
XUL は chrome の実装に使用されているので、高度な権限を持ったサービスへのアクセスが必要だ。 chrome 内の全コードは信頼できるものであるべきだ。つまり、chrome へコードをインストールする事は 権限を持った動作だ。skin はどんなコードも含んでおらず、 いかなる強力な安全防護対策なしのインストールも安全なはずであることをに注意しなさい。XUL のコードはウェブコンテンツとやり取りできる。だが、私たちは確実に、 ウェブコンテンツが権限を持った XUL のコードとやり取りできないようにしなければならない。 ウェブコンテンツは、prototype 連鎖あるいは JavaScript の "caller" プロパティによって侵害できない sandbox の中に収まっていなければならない。
RDF
サイドバーを経由して、RDF コンテンツを信頼できないサーバーから直接取り出し、 他の RDF コンテンツと共に集める事ができる。JavaScript イベントハンドラや リンクの取り消しのような、潜在的な危険要素を取り除く事ができる RDF 用フィルタが必要となる。多くの RDF データソースはセキュリティの利点を反映する。 一番明白なのはファイルシステムだが、chrome レジストリのようなその他のものも同様にセキュリティの影響を及ぼす。 私たちは信頼できないコードから RDF に直接アクセスするのを禁止するべきだ。