Sponsored Link •
Guarding restricted packages
Java allows classes in the same package to grant each other special access privileges that aren't granted to classes outside the package. So, if your class loader receives a request to load a class that by its name brazenly declares itself to be part of the Java API (for example, a class named
java.lang.Virus), your class loader should
proceed cautiously. If loaded, such a class could gain special access
to the trusted classes of
java.lang and could possibly use
that special access for devious purposes.
Consequently, you would normally write a class loader so that it simply refuses to load any class that claims to be part of the Java API (or any other trusted runtime library) but that doesn't exist in the local trusted repository. In other words, after your class loader passes a request to the primordial class loader, and the primordial class loader indicates it can't load the class, your class loader should check to make sure the class doesn't declare itself to be a member of a trusted package. If it does, your class loader, instead of trying to download the class across the network, should throw a security exception.
Guarding forbidden packages
In addition, you may have installed some packages in the trusted repository that contain classes you want your application to be able to load through the primordial class loader, but that you don't want to be accessible to classes loaded through your class loader. For example, assume you have created a package named
installed it on the local repository accessible by the primordial class
loader. Assume also that you don't want classes loaded by your class
loader to be able to load any class from the
package. In this case, you would write your class loader such that the
very first thing it does is to make sure the requested class doesn't
declare itself as a member of the
If such a class is requested, your class loader, rather than passing
the class name to the primordial class loader, should throw a security
The only way a class loader can know whether or not a class is from a
restricted package, such as
java.lang, or a forbidden
package, such as
absolutepower, is by the name of the class.
Thus, a class loader must be given a list of the names of restricted and
forbidden packages. Because the name of class
java.lang.Virus indicates it is from the
java.lang package, and
java.lang is on the
list of restricted packages, your class loader should throw a security
exception if the primordial class loader can't load it. Likewise,
because the name of class
indicates it is part of the
absolutepower package, and the
absolutepower package is on the list of forbidden
packages, your class loader should throw a security exception.
A security-minded class loader
A common way to write a security-minded class loader is to use the following four steps:
By performing steps one and three as outlined above, the class loader guards the borders of the trusted packages. With step one, it prevents a class from a forbidden package to be loaded at all. With step three, it doesn't allow an untrusted class to insert itself into a trusted package.
The class loader architecture contributes to the JVM's security model in two ways:
Both of these capabilities of Java's class loader architecture must be used properly by programmers so as to reap the security benefit they offer. To take advantage of the name-space shield, code from different sources should be loaded through different class loader objects. To take advantage of trusted package border guarding, class loaders must be written so they check the names of requested classes against a list of restricted and forbidden packages.
For a walk through of the process of writing a class loader, including sample code, see Chuck McManis's JavaWorld article, "The basics of Java class loaders."
In next month's article, I'll continue the discussion of the JVM's security model by describing the class verifier.
About the author
Bill Venners has been writing software professionally for 12 years. Based in Silicon Valley, he provides software consulting and training services under the name Artima Software Company. Over the years he has developed software for the consumer electronics, education, semiconductor, and life insurance industries. He has programmed in many languages on many platforms: assembly language on various microprocessors, C on Unix, C++ on Windows, Java on the Web. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill. Reach Bill at email@example.com.
This article was first published under the name Security and the Class Loader Architecture in JavaWorld, a division of Web Publishing, Inc., August 1997.