Page History

Class loaders 's allow an application to dynamically extend a Java application at runtime by loading classes.  For each class it loads, the JVM keeps track of which class loader loaded the class. When a loaded class first refers to another class, the virtual machine requests the referenced class from the same class loader that originally loaded the referencing class. 

Java's class loader architecture controls interaction between code loaded from different sources by using different allowing the use of different class loaders. This separation of class loaders is fundamental to load code from different sources.  This the separation of code and prevents malicious code from gaining access to and subverting trusted code.  A .  Hence, it is important to preserve this separation. A class loader that loads untrusted code should not interact with trusted code that invokes any of the methods from the following table:

Certain standard APIs in the core libraries of the Java runtime enforce SecurityManager checks but allow those checks to be bypassed depending on the immediate caller's class loader. When the java.lang.Class.newInstance method is invoked on a Class object, for example, the immediate caller's class loader is compared to the Class object's class loader. If the caller's class loader is an ancestor of (or the same as) the Class object's class loader, the newInstance method bypasses a SecurityManager check. (See Section 4.3.2 in [1] for information on class loader relationships). Otherwise, the relevant SecurityManager check is enforced.

The difference between this class loader comparison and a SecurityManager check is noteworthy. A SecurityManager check investigates all callers in the current execution chain to ensure each has been granted the requisite security permission. (If AccessController.doPrivileged was invoked in the chain, all callers leading back to the caller of doPrivileged are checked.) In contrast, the class loader comparison only investigates the immediate caller's context (its class loader). This means any caller who invokes Class.newInstance and who has the capability to pass the class loader check--thereby bypassing the SecurityManager--effectively performs the invocation inside an implicit AccessController.doPrivileged action. Because of this subtlety, callers should ensure that they do not inadvertently invoke Class.newInstance on behalf of untrusted code.

        package yy.app;

        class AppClass {
           OtherClass appMethod() throws Exception {
               return OtherClass.class.newInstance();
           }
        }

        +--------------------------------+
        | xx.lib.LibClass                |
        |   .LibClass                    |
        +--------------------------------+
        | java.lang.Class                |
        |   .newInstance                 |
        +--------------------------------+
        | yy.app.AppClass |<-- AppClass.class.getClassLoader
        | .appMethod |       determines check
        +--------------------------------+

        |                                |

Code has full access to its own class loader and any class loader that is a descendent. In the case of Class.newInstance access to a class loader implies access to classes in restricted packages (e.g., sun.* in the Sun JDK).

In the diagram below, classes loaded by B have access to B and its descendents C, E, and F. Other class loaders, shown in grey strikeout font, are subject to security checks.

        +-------------------------+

        | bootstrap loader | <--- null
        +-------------------------+
         ^ ^
        +------------------+ +---+

        | extension loader | | A |
        +------------------+ +---+
         ^
        +------------------+

        | system loader | <--- Class.getSystemClassLoader()
        +------------------+
         ^ ^
        +----------+   +---+

        | B |   | F |
        +----------+   +---+
          ^      ^     ^

        +---+  +---+   +---+
        | C |  | E |   | G | 
        +---+  +---+   +---+
          ^
        +---+
        | D |
        +---+

...

Classes that have the same defining class loader exist in the same namespace but may have different privileges, depending on the security policy. Security vulnerabilities can also arise when trusted code coexists with untrusted code (or less privileged code) that was loaded by the same defining class loader. In this case, the untrusted code can freely access members of the trusted code according to their declared accessibility. When the trusted code uses any of the tabulated APIs, no security manager checks are carried out (with the exception of loadLibrary and load).

...

With the exception of loadLibrary() and load() methods, the tabulated methods do not perform any security manager checks. Because the The loadLibrary and load APIs are typically used from within a doPrivileged block and, in that case, unprivileged callers can directly invoke them without requiring any special permissions. That means that the security manager checks are curtailed at the immediate caller and the entire call stack is not examined, resulting in no enhanced security. Accepting tainted inputs from untrusted code and allowing them to be used by these APIs may also expose vulnerabilities.

This guideline is an instance of SEC04SEC03-J. Protect sensitive operations with security manager checksDo not load trusted classes after allowing untrusted code to load arbitrary classes. Many examples also violate SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary.

...