Understanding Security and Class Loaders

Class loading is at the center of the Java security model. After all, if a rogue third party were to get an application to load a custom version of java.lang.String that had the nasty side effect of deleting the hard drive whenever it was instantiated, it would be problematic for users and for Sun. Understanding the security features of the class loader architecture will help you understand how Tomcat’s class loader system works.

The Java class loader architecture tackles the security problem with the following strategies:

  • Class loader delegation

  • Core class restriction

  • Separate class loader namespaces

  • Security manager

Class Loader Delegation

The delegation model is often described as a security feature. After all, it seems like it should be: anyone trying to load false versions of the core Java classes will fail because the bootstrap class loader has priority and will always find the genuine copies of the core Java classes.

However, the delegation model is flawed as a security mechanism because class loaders aren’t required to implement it. In other words, if you want to create a class loader that doesn’t follow the delegation model, you’re free to do so.

So, if a custom class loader doesn’t have to delegate requests to the system class loader, what’s to stop a custom class loader from loading its own copy of java.lang.String?

Core Class Restriction

Fortunately, it’s not possible for any class loader written in Java to instantiate a core Java class. The ClassLoader abstract class, from which all class loaders must descend, blocks the creation of any class whose fully qualified name begins with java. Thus, no false java.* classes are allowed. As the bootstrap class loader isn’t written in Java and doesn’t descend from ClassLoader, it’s not subject to this restriction.

By implication, this restriction indicates that all class loaders must at least delegate to the bootstrap class loader; otherwise, when the class is loaded, the class loader has no way to load java.lang.Object, from which all objects must descend.

Thus, the delegation model by itself doesn’t provide security. It’s the core class restriction mechanism that prevents rogue class loaders from tampering with the core Java libraries (at least at run time).

Separate Class Loader Namespaces

As you saw earlier, each class loader has its own namespace, so you can load two different classes with the same fully qualified name. Having separate namespaces is an important security feature because it prevents custom class loaders from stepping over each other or the system class loader. No matter how hard a renegade class loader may try, it can’t replace a class loaded by a different class loader; furthermore, it can’t access the package-private members in classes of a package with the same name that was loaded from a different location.

Security Manager

If developers really want to make sure no one can damage their programs with custom class loaders, they can simply disallow the use of custom class loaders altogether with the SecurityManager class. This is Java’s general mechanism for applying security restrictions in applications.

With a security manager, and its associated policy files, you can disallow (or allow) a large number of tasks. For example, you can prevent a program from opening any socket to some network host or prevent it from opening any file on the local file system. More appropriately, you can also prevent an application from loading a class loader. In fact, you have the following options for preventing class loader–related operations:

  • You can prevent the loading of any class loader.

  • You can prevent a reference to any class loader being obtained (including the system class loader).

  • You can prevent the context class loader of any thread being changed.

You have to perform only two steps.

  1. Configure a policy file with the permissions you want for a given application.

  2. Turn on the application’s security manager.

There’s a lot more to the security manager than this, but the complexity of the topic means that Chapter 12 is devoted to the subject.



Pro Jakarta Tomcat 5
Pro Apache Tomcat 5/5.5 (Experts Voice in Java)
ISBN: 1590593316
EAN: 2147483647
Year: 2004
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net