27 特権付きコードとサンドボックス・コードの混合

27.1 ユーザー向けの混合コード保護オプション

混合コード・プログラムの処理方法を管理するためのメカニズムが2つ用意されています。

27.2 混合コードの警告なしの特権付きのアプリケーションおよびアプレットのセキュアなデプロイ

この項では、開発者とデプロイヤ向けに、信頼できるコンポーネントを信頼できないコンポーネントで置き換えることによって、Java Web Startアプリケーションとアプレットが悪用されることを防止するためのベスト・プラクティスについて説明します。

Java SE 6 Update 19以降、特権付きのJava Web Startアプリケーションとアプレットをデプロイするための2つのJARマニフェスト属性が使用可能になりました。これらのマニフェスト属性のいずれかを含めた場合、警告ダイアログは表示されません。

開発者とデプロイヤは、自身のJava Web Startアプリケーションとアプレットをチェックし、特権付きコードと信頼できないコードが混在しているか確認すべきです。それらのアプリケーションとアプレットのユーザーが、それらのアプリケーションとアプレットを間違って悪意のあるWebサイトからダウンロードする可能性がある場合には、次のいずれかの属性を指定して配備または再配備することを検討すべきです。既存の署名付きJARにこれらのマニフェスト属性を追加したあと、JARに署名し直す必要があります。マニフェスト・エントリを指定したときの再署名には、クラスのソース・コードおよびリソースは不要です。

27.3 混合コードに関するFAQ

アプリケーションの開発やデプロイを担当しています。この問題の心配をする必要があるかどうかは、どのようにしてわかりますか。

影響があるかどうかを判別するために実行可能なテストはありますか。

回答: 最新バージョンのJREを使用して、アプレットおよびJava Web Startアプリケーションをテストします。警告ダイアログが表示された場合、そのアプリケーションには混合コードが含まれています。

どのようなアクションを取ることができますか。

回答: エンド・ユーザーは、警告ダイアログへの応答で「ブロック」または「ブロックしない」のどちらをクリックするかを決定する前に、「詳細情報」リンクをクリックできます。IT管理者またはシステム管理者であれば、前述の対応する配備プロパティを使って、混合コード保護オプションのいずれかを選択し、企業内のデスクトップを構成できます。開発者およびデプロイヤであれば、改ざんを防止するためにマニフェスト・エントリを使ってアプリケーションを保護できます。これらのマニフェスト・エントリのいずれかを使用した場合、警告ダイアログは表示されません。

JavaのISV、OEM、およびアプリケーション・ベンダーは自身のコードに対して何をする必要がありますか。

インターネットからのJavaアプレットおよびJava Web Startアプリケーションについてはどうですか。それらについて心配する必要がありますか。

回答: Java Web StartアプリケーションやJavaアプレットに混合コードが含まれていれば、それがインターネット、イントラネットのどちらからダウンロードされたものであっても、ユーザーに警告ダイアログが表示されます。

企業のファイアウォールの内側にいる場合はどうですか。

これはOracle JRockitの問題ですか。

回答: いいえ。

別のベンダーのJavaの実装を使用しています。これらも同じように影響がありますか。

回答: ベンダーに問い合せて、そのベンダーの実装に関する助言を得てください。

開発者です。この拡張機能で追加されたセキュリティ例外は、どのようなものですか。

回答: 次のSecurityExceptionメッセージは、情報およびデバッグのためだけに記述されています。実際のメッセージの内容は、実装やリリースによって変わる可能性があります。

これらのSecurityExceptionがスローされるのは、JARファイルにマニフェスト属性のいずれかが含まれ、そのJARファイル自体に信頼できないコンポーネントが含まれていた場合です。

attempted to open sandboxed jar "+ url +" as Trusted-Only
attempted to open sandboxed jar "+ url +" as Trusted-Library

次のSecurityExceptionがスローされるのは、JARファイルにTrusted-Onlyマニフェスト属性が含まれ、信頼できないコンポーネントへのアクセスが以前に行われていた場合です。

attempted to open Trusted-Only jar "+ url +" on sandboxed loader

次のSecurityExceptionがスローされるのは、Trusted-Onlyマニフェスト属性を含むJARが少なくとも1つ開かれ、そのあとで信頼できないコンポーネントをロードすることが試みられた場合です。

Trusted-Only loader attempted to load sandboxed resource from "+ url"

次の2つのSecurityExceptionがスローされるのは、まず混合コンポーネントが検出され、混合を許可しないことが決定された場合です。最初の場合は、以前にロードされたものがすべて信頼できるもので、そのあと、信頼できないコンポーネントをロードすることが試みられました。2番目の場合はその逆の条件です。

trusted loader attempted to load sandboxed resource from "+ url"
sandboxed loader attempted to load trusted resource from "+ url"

次の2つのSecurityExceptionがスローされるのは、以前に混合コンポーネントが検出されていて、それらの共存を許可することが決定されたあとです。この例外は、信頼できるコンポーネントと信頼できないコンポーネントの間でコンポーネント名(リソース名またはクラス・パッケージ名)の競合が検出され、そのリソースまたはクラスのロード要求が拒否されたことを示しています。

"resource \"" + name + "\" does not match trust level of other resources of the same name"
"class \"" + packageName + "\" does not match trust level of other classes in the same package"

次の2つのSecurityExceptionがスローされるのは、信頼できないコンポーネントへのアクセスが以前に行われ、信頼できるコンポーネントをロードする試みが以前に検出され、混合コンポーネントの共存を許可することが決定され、信頼できるコンポーネントを含むJARが開かれ、信頼できるコンポーネントと信頼できないコンポーネントとの間でコンポーネント名の競合が検出された場合です。

"untrusted resource \"" + name + "\" in class path"
"untrusted class package \"" + packageName + "\" in class path"

Trusted-Libraryマニフェスト属性を使用するように簡単には更新できない混合コードJava Web Startアプリケーションがあります。all-permissionsセキュリティ・モデルを要求するようにJNLPを変更しなくても、サンドボックス内のJNLPに含まれるJARファイルに署名できますか。

回答: はい。ただし、いくつかの制限があります。サンドボックス内のJARファイルの署名は、all-permissionsセキュリティ・モデルを使用するJNLPファイル内の1つ以上の信頼できるJARファイルと同じ署名証明書を使用して行う必要があり、信頼できるJARファイルがJava Web Startによって開かれた後で、同じ署名者を共有するすべてのサンドボックス内のリソースがロードされる必要があります。つまり、信頼できるJARファイルが、Java Web StartのJAR検索順の前のほうに存在している必要があり、そうしないと単純な検索順とは無関係にJARインデックス機能を使用してロードされるようにトリガーされます。Java Web Startでは、まずメイン・アプリケーションJNLPのJARが、次にすべてのJNLP拡張が宣言された順番で検索されます。JNLP内では、まず「eager」というラベルの付いたJARファイルが検索され、次に「lazy」のJARファイルが検索され、続いて「part」機能を使用するというラベルの付いたすべてのJARファイルが検索されます。

私の電話にはJavaが搭載されています。それはこの問題の影響を受けますか。

回答: いいえ、Java MEには影響はありません。

27.4 詳細情報