Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

Automatic Memory Management and Garbage Collection

In C or C++, the programmer is responsible for allocating and deallocating memory and needs to keep track of the pointers to all the objects in memory. This can result in memory leaks, dangling pointers, null pointers, and other defects that are difficult to find and fix. Additionally, leaving memory management up to the programmer can allow for mischief. Manual allocation and deallocation of memory opens the door for unauthorized replication of objects, impersonation of trusted objects, and attacks on data consistency. By having automatic memory management, Java gets around these problems and, at the same time, makes life easier for the programmer. The following example shows how a programmer might go about impersonating a trusted class (for instance, the ClassLoader) if Java did not have automatic deallocation of memory. First, the program would create a legitimate object of class MyFakeClassLoader and make a reference to that object. Now, with a little sleight of hand and knowledge of how allocation and deallocation work, the programmer removes the object from memory but leaves the reference. He or she then instantiates a new instance of ClassLoader, which happens to be the exact same size, in the same memory space, and voila! The pointer now refers to the other class, and the programmer has access to methods and variables that are supposed to be private. This scenario is not possible in Java because of the automatic memory management. The Java automatic memory management system doesn’t allow manual manipulation of references.

The SecurityManager Class

The Java security model is open to extension when new holes are found. A key to this is the SecurityManager class. This class is a generic class for implementing security policies and providing security wrappers around other parts of Java. This class does not get used by itself—it is simply a base for implementing security in other classes. Actual implementation of security in other objects is accomplished through subclassing the SecurityManager class. Although not a comprehensive list, this class contains methods to

•  Determine whether a security check is in progress

•  Check to prevent the installation of additional ClassLoaders

•  Check if a .class file can be read by the Java Virtual Machine

•  Check if native code can be linked in

•  Check if a file can be written to

•  Check if a network connection can be created

•  Check if a certain network port can be listened to for connections

•  Check if a network connection can be accepted

•  Check if a certain package can be accessed

•  Check if a new class can be added to a package

•  Verify security of a native OS system call

•  Prevent a new Security Manager from being created

As you might guess from the preceding list, the names of many of the methods in the java.lang.SecurityManager class begin with check. All but one of these checkXXX methods return if all is well or throw a SecurityException if there was a problem. Only checkTopLevelWindow returns a value—a Boolean.

The following example of the use of the checkXXX methods is based on that in the Java 1.2 API documentation (found at http://java.sun.com/products/jdk/1.2/docs/api/java.lang.SecurityManager.html) for java.lang.SecurityManager:

SecurityManager secMgr = System.getSecurityManager();

if (secMgr != null) {

    secMgr.checkXXX(arguments go here,… );

}

Everything discussed so far in this section has been about Java as a whole. The language has no pointers whether you are working with applets or applications. The bytecode verifier and class loading mechanisms still apply. Applications in Java function like any other applications in any full-featured language, including direct memory access through use of native code. Some limitations on applets exist, however, that do not apply to applications.

Time-Tested Applet Security

Java would not have made the splash that it did only by being cross platform and object oriented. It was the Internet and applets that put it on the cover of Time magazine. The Internet is also where the biggest risks come for Java applets.

Applets are limited Java programs, extended from class Applet, that execute within the user’s Web browser. Applets usually load from remote machines and are subject to severe limitations on the client machine.

Untrusted applets arriving on the client machine are subject to the following file system and network restrictions:

•  Cannot read or write files on the local file system.

•  Cannot create, copy, delete, or rename files or directories on the local file system.

•  Can only connect to the machine from which they originally came. This is the URL of the source machine as specified in the APPLET tag in the HTML document or in the CODEBASE parameter of the APPLET tag. This cannot be a numeric IP address.

•  Cannot call external programs.

•  Cannot manipulate Java threadgroups other than their own.

•  Cannot run outside the Java Virtual Machine’s memory area.

---

NOTE:  This set of restrictions on the applet can vary slightly from one implementation of Java to another. All these apply, for instance, when using Netscape Navigator 2.0 or later, but the JDK appletviewer enables you to designate an explicit list of files that can be accessed by applets. The HotJava browser, Netscape Navigator, Microsoft Internet Explorer, and the JDK appletviewer (to name a few) all have minor differences ranging from handling of certain exceptions to access control lists for applets. If you want to know of detailed limitations for a particular browser, go to the applicable Web site and get the most up-to-date information. For the Microsoft Internet Explorer, check http://www.microsoft.com/ie/security/, and for the Netscape Navigator, check http://home.netscape.com/comprod/products/communicator/navigator.html. If you need to have a consistent security model no matter where your applet runs, consider designing your Web pages to load Sun’s Java plug-in instead of relying on the browser’s JVM.

---

•  For more information on the Java plug-in, see “Running the Applet” on p. 992.