Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Java security: How to install the security manager and customize your security policy

Learn about the security manager and the Java API, what remains unprotected by the security manager, and security beyond the JVM architecture

By Bill Venners, JavaWorld.com, 11/01/97

This month's article continues the discussion of Java's security model that began in August's "Under the Hood." In that article, I sketched overview of the security mechanisms built into the Java virtual machine (JVM). I also looked closely at one aspect of those security mechanisms: the JVM's built-in safety features. In September's column I examined the class loader architecture, and in the October column, the class verifier. In this installment of the security series, I describe the security manager -- the fourth and final piece of the JVM's core security architecture -- and I finish up with a brief discussion of the ways in which Java's security strategy extends beyond the JVM's architecture.

The security manager and the Java API

As described in last month's "Under the Hood," you can prevent code loaded by different class loaders from interfering with one another inside the JVM by using a class-file verifier. But to protect assets external to the Java virtual machine, you must use a security manager. The security manager defines the outer boundaries of the sandbox. (For a refresher on the Java sandbox, see the first section of my August "Under the Hood" column.)

A security manager is any class that descends from class java.lang.SecurityManager. Because they are written in Java, security managers are customizable. A security manager allows you to establish a custom security policy for an application.

The Java API enforces the custom security policy by asking the security manager for permission to take any action before it does something that potentially is unsafe. For each potentially unsafe action, there is a method in the security manager that defines whether or not that action is allowed by the sandbox. Each method's name starts with "check," so, for example, checkRead() defines whether or not a thread is allowed to read to a specified file, and checkWrite() defines whether or not a thread is allowed to write to a specified file. The implementation of these methods is what defines the custom security policy of the application.

Most of the activities that are regulated by a "check" method are listed below. The classes of the Java API check with the security manager before they:

• Accept a socket connection from a specified host and port number
• Modify a thread (change its priority, stop it, and so on)
• Open a socket connection to a specified host and port number
• Create a new class loader
• Delete a specified file
• Create a new process
• Cause the application to exit
• Load a dynamic library that contains native methods
• Wait for a connection on a specified local port number
• Load a class from a specified package (used by class loaders)
• Add a new class to a specified package (used by class loaders)
• Access or modify system properties
• Access a specified system property
• Read from a specified file
• Write to a specified file

Because the Java API always checks with the security manager before it performs any of the activities listed above, the Java API will not perform any action forbidden under the security policy established by the security manager.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.