Friday, March 23, 2007

Security and the Java classloader

The Java classloader plays an important part in the overall security of a Java application.

The classloader works along with the SecurityManager and the Access Controller to make a Java system secure. The classloader is important because it is the entity that first loads the classes. The classloader knows the codebase from where the code was loaded, and if the code was signed. The classloader works in three ways to help make a Java system secure:

  1. It helps the JVM to maintain the integrity of namespaces.
  2. It maps permissions with each class. The permissions associated with every class are also known as the protection domain of the class. This mapping helps the access controller determine which classes have which permissions.
  3. It ensures that code which accesses or defines classes has the appropriate permissions to do so. The classloader works in conjunction with the SecurityManager to enforce this.
Each of these topics are fairly long, and I will not go into intricate details. I will however explain the first topic briefly below.

Definition of namespaces:
We all know that each class in Java is uniquely identified by it's package name. But that's not all. In reality a class is uniquely identified by it's fully qualified name and the classloader that loaded it. Can you imagine why this is needed? It is needed to prevent the integrity of code that is running in Applets. Assume you load Applets from and some malicious website in your browser. If the malicious website uses package names such as com.sun.*, then it is possible that their classes might be used when the Applet from tries to invoke a class, thus causing damage. However this will not happen because classes are unique to the package name and the classloader that loaded them. A different instance of the classloader is used to load the Applet from and the Applet from the malicious website. Hence even if both of them use classes with the same package names, unique instances of these classes will be created for both the Applets amd they will not be able to access each other's classes.

Mapping permissions of classes:
We can configure the Java policy file to restrict or allow certain actions to code loaded from a particular codebase. We can also grant certain priviledges to code that has been signed by a trusted entity. For example we might want to provide I/O access to Applet code that has been signed by It is the classloader that helps in managing this information. The classloader works in conjunction with the security manager and the access controller to enforce the permissions.
You might want to read the links below to better understand how the classloader works.


Notes: This text was originally posted on my earlier blog at

No comments: