Java ClassLoader Security Model

Question

I am trying to understand the security model used when the JVM is prompted to load classes.

From the JVM specification in the sandbox, I am given the ClassLoader that the standard JVM implementation must support at least one more ClassLoader , regardless of the primordial ClassLoader . This is used to load application class files (for example, from the provided class).

If a class is requested from a ClassLoader that is not in this namespace, for example, java/lang/String , then it forwards the request to the original ClassLoader , which tries to load the class from the Java API, if it is not there, it throws a NoClassDefFoundError .

I correctly understood that primordial ClassLoader only loads classes from the Java API namespace, and all other classes are loaded through a separate implementation of ClassLoader ?

And this makes loading classes more secure because it means that the malicious class cannot be masked as a member of the Java API (say java/lang/Virus ) because it is a protected namespace and cannot be used in the current ClassLoader ?

But is there something to prohibit replacing Java API classes with malicious classes, or would it be detected during class validation?

Answer 1

For historical reasons, the names used for class loaders are a bit strange. The bootloader loads the system classes. By default, the system class loader loads classes from the class path, not system classes. System classes are located in jre / lib (mainly in rt.jar), supported directories, and anywhere added via -Xbootclasspath .

In Sun / Oracle, the JRE rt.jar contains classes with packages starting with java., Javax., Sun., Com.sun., Org.omg, org.w3c, and org.xml.

Invalid code (including configuration) should not be added to system classes. Some package name prefixes may be limited by the security property. Java. the prefix is ​​specially protected for non-technical reasons.

Typically, the class loader will delegate it to the parent element before defining a new class, not allowing any classes from the ancestor loader to be replaced. Java EE recommends (even if Java SE prohibitions), with some class loaders, prefer their own classes, usually using a more modern API or other implementation. This allows you to obscure classes, but only as seen through this bootloader (and its children). All other classes continue to refer to the original.