Java ClassLoaderセキュリティモデル

Question

JVMにクラスの読み込みが要求されたときに使用するセキュリティモデルを理解しようとしています。

Sandboxingに関するJVM仕様から、標準のJVM実装では、を少なくとも1つ保持して、primordial ClassLoaderとは独立していると考えられます。これはアプリケーションクラスファイルをロードするために使用されます（例えば、提供されたクラスパスから）。その後、

クラスはそれで、たとえば、名前空間、java/lang/StringですされていないClassLoaderから要求された場合、そのことがあった場合、それは、Java APIのからクラスをロードしようとした、原始ClassLoaderに要求を転送するには、 NoClassDefFoundErrorがスローされます。

原文のClassLoaderはJava APIネームスペースからクラスをロードするだけで、他のすべてのクラスは個別のClassLoader実装を介してロードされると思いますか？

そして、それは悪質なクラスは、Java APIのメンバーになりすますことができないことを意味するので、これはより安全なクラスのロードを作ることは、これは保護された名前空間で、現在のClassLoaderで使用することはできませんので（java/lang/Virusを言うことができます） ？

Java APIのクラスが悪意のあるクラスに置き換えられないようにしたり、classの確認中に検出されることはありますか？

Answer 1

歴史的な理由から、クラスローダーに使用される名前はちょっと変わったものです。ブートクラスローダーは、システムクラスをロードします。システムクラスローダは、デフォルトでは、システムクラスではなくクラスパスからクラスをロードします。システムクラスは、jre/lib（主にrt.jar）にあり、承認されたディレクトリと、-Xbootclasspathによって追加された場所です。

Sun/Oracle JRE上で、rt.jarには、java。、javax。、sun。、com.sun。、org.omg、org.w3cおよびorg.xmlで始まるパッケージのクラスが含まれています。

信頼できないコード（設定を含む）は、システムクラスに追加できません。接頭辞の付いたパッケージ名の中には、セキュリティプロパティーによって制限されるものがあります。 Java。接頭辞は技術的でない理由で特別に保護されています。

一般に、クラスローダーは、新しいクラスを定義する前にその親に委譲し、祖先ローダーのクラスが置き換えられないようにします。 Java EEでは、一部のクラスローダーを持つ（たとえJava SE禁止でも）独自のクラスを使用することを推奨しています（通常は、より最新のAPIまたは別の実装を使用することを推奨します）。これにより、クラスのシャドーイングが可能になりますが、そのローダー（およびその子）を通してのみ見られます。他のクラスはすべて元のクラスにリンクし続けます。