Building a bigger sandbox -
JavaWorld -
August 1998
Tutorial Details:
Building a bigger sandbox
Building a bigger sandbox
By: By Todd M. Greanier
Security in JDK 1.2 gives developers more control. Find out how to take advantage of this flexible new model
he sandbox. Discussions of Java's security model always seem to involve mention of the so-called sandbox security model. This article won't delve deeply into this topic; instead, we'll discuss how new additions to the Java API in the 1.2 release let us expand the original sandbox idea, create our own sandboxes, and even eliminate the sandbox entirely.
The security manager and the sandbox
Java has always had many different faces to its security model. It has a strongly typed compiler to eliminate programming bugs and help enforce language semantics, a bytecode verifier that makes sure the rules of Java are followed in compiled code, a classloader that's responsible for finding, loading, and defining classes and running the verifier on them, and the security manager -- the main interface between the system itself and Java code.
We'll be concentrating on the age-old security manager and the new addition to the JDK, the access controller. To refresh our memories, the security manager in Java is composed of a series of checkXXX methods that we can override, defining the logic we desire. In JDK 1.1, this logic either disallows the request (by throwing a java.lang.SecurityException ) or allows the request (either via some ornate logic scheme or by simply returning).
Security managers exist to enforce the rules of the sandbox. The sandbox concept is fairly simple: When you run a piece of Java code, you may want the sandbox to provide an area for the code to do what it needs to do. But in many situations, you need to restrict the bounds of this area. Code that is trusted resides outside the sandbox; code that is untrusted is confined within it. Trusted code is the code in the Java API and code loaded from the classpath. Untrusted code is code loaded from outside the classpath, usually from the network. So Java applications, by default, live outside the sandbox and Java applets, by default, are confined within it.
The need for this "play area" is obvious when you think of an applet. Suppose a site called www.badpeople.com decided to create an applet that ostensibly showed slides of Sunday cartoons. You might enjoy that. But behind the scenes, while you were lazily chuckling at the sideshow, the applet would really be scouring your hard drive for private information. Without the sandbox, this scenario is all too possible. The sandbox represents the limits a program has put upon it. The sandbox is another term for a security policy.
As Java grows, the need for varying security policies increases. It is agreed by almost everyone that the original sandbox model of JDK 1.0.x, though safe, was too restrictive. With JDK 1.1 the addition of digital signatures allowed expansion of the original sandbox policy. If the user trusted the digitally signed code, users could allow normally untrusted code to access resources. (Though their discussion is beyond the scope of this article, digital signatures still play an important role in JDK 1.2.)
The sandbox, though, is just the security policy -- the equivalent of a law. And a policy or law must be enforced to be effective. The government can pass a law in your town tomorrow outlawing red shoes, but if nobody enforces it, it's not much of a law. The sandbox won't effectively confine code and its behavior without an enforcement mechanism. This is where the security manager comes into the picture. Security managers make sure all restricted code stays in the sandbox.
Here's an example of how to create a security manager in JDK 1.1 that allows reading files, but disallows writing files:
public class MySecurityManager extends java.lang.SecurityManager {
public void checkRead(String file) throws SecurityException {
// reading is allowed, so just return
return;
}
public void checkWrite(String file) throws SecurityException {
// writing is not allowed, so throw the exception
throw new SecurityException("Writing is not allowed");
}
} // end MySecurityManager
The MySecurityManager class does its job, but in a purely binary fashion: Either you can perform the requested action or you cannot. Often it is desirable to maintain a little more granularity in the system. Perhaps you want to permit reading, but only from files ending in txt. This might be achieved if we change the previous code as follows:
public class MySecurityManager2 extends java.lang.SecurityManager {
public void checkRead(String file) throws SecurityException {
//check the file extension to see if it ends in ".txt"
int index=file.lastIndexOf('.');
String result=file.substring(index, file.length());
if(result.equalsIgnoreCase(".txt")){
return;
}else{
throw new SecurityException("Cannot read file: "+file);
}
}
} // end MySecurityManager2
This version of the code offers a little more fine-tuned control than the original. With work, we could create a security manager that had very a granular security policy. This format -- subclassing java.lang.SecurityManager and overriding the appropriate methods -- was the only way security was controlled prior to JDK 1.2. This system offers many advantages:
It is very easy to provide a binary security model (yes, you can or no, you can't)
The methods in the SecurityManager class are called for you by the Java API; there's no need for you to call the code at all
The interface of this system is constant across all JVM platforms; one security manager can run everywhere
The additional size of a simple security manager is negligible
The security manager and class loader work hand-in-hand to ensure neither is compromised by accident or an act of evil
The traditional model of Java security falls short, however, when it comes to flexibility and intricate granularity. Its disadvantages as follows:
The control of security is in the developer's hands, not in a security specialist's hands
It's not easy to provide a customizable security model that varies from user to user
The only way to change an existing policy is to change or subclass the existing security manager; not all users have the capability of programming in Java
New security policies (non-system resource policies, for example) are difficult to implement
These disadvantages are erased with the security architecture of JDK 1.2 while the advantages remain.
Enter the access controller
Our discussion so far indicates that the traditional sandbox model, though useful, is simply not flexible enough for most systems. What may be a good policy today may not be appropriate tomorrow. A user could need his access level changed over time, not an easy thing to accomplish with the traditional security model. To provide greater control to both the developer and the end user, the java.security package was expanded to include classes like AccessController , Permission , and Policy . We'll discuss the Permission and Policy objects a bit later.
The AccessController is the muscle of the security manager. The sandbox, remember, is the policy in effect. The security manager enforces this policy by making use of the AccessController . In JDK 1.2, the SecurityManager class has the same interface as prior releases (allowing for backward compatibility), but the logic has changed. Now each checkXXX method makes a call to a static method inside the AccessController class. When you call the checkRead(String file) method now, it defers the work to the AccessController .
Let's assume a user, Grover, wants to access a file called joe.rec. Compile-time isn't the best time to set security boundaries, as it isn't yet known who that user will be. It makes more sense to discover whether or not Grover can access the file at runtime . Someone, probably a security administrator, could create a policy file containing Grover's permissions. The flow of this process is given in the diagram below.
Security Flow Diagram
I've simplified the procedure here; the code samples aren't literally from the source code, but the functionality is exactly the same. The important thing to understand here is that the SecurityManager is no longer solely responsible for the logic of the desired security policy. In fact, it could be said that the SecurityManager is no longer needed in the JDK. There are a few reasons it has remained part of the system, but the main one is to ensure that code written with previous versions of the JDK will still function. Remember that the methods inside the SecurityManager are just that: methods. You can perform any logic you choose inside them. If you're using a Java program from an earlier release of the JDK and there is a security manager installed for it, the code does not have to be changed to still work. The original logic will apply for all the methods you overrode and the AccessController will be called for the rest.
Now we'll look at how the AccessController works with user-defined policies.
The access controller, permissions, and policies
If you look at the above diagram , you'll see that when the SecurityManager 's checkRead(String file) method is called, it creates a FilePermission object. It then passes this FilePermission object to the AccessController , which compares it to the current Policy object for acceptance or denial.
Whew!
The good news is, all of this calling of methods and passing of objects is handled for you by the Java API. Though there are times when you may wish to create your own Permission objects or call the AccessController yourself, we'll leave discussion of that for a future article. What we need to define now are the system-provided permissions we wish to allow a program to have and the policy file those permissions will be stored in.
A permission in Java represents a specific access privilege. The abstract java.security.Permission class is subclassed to create specific permission types. To represent a f
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Building a bigger sandbox -
JavaWorld -
August 1998
View Tutorial: Building a bigger sandbox -
JavaWorld -
August 1998
Related
Tutorials:
 How to write
a Java Card applet: A developer's
guide
How to write
a Java Card applet: A developer's
guide
|
Java security evolution
and concepts, Part 2
Java security evolution
and concepts, Part 2
|
Update distributed applications
Update distributed applications
|
Software Download Central
compatible.
GNU getopt - Java port
A while back I found myself in need of a Java command line option parser. Unsatisfied with free versions I was able to find on the net, I volunteered to port the GNU getopt family of functions from C to Java. The current release
|
Turn EJB components into Web services
Summary
Web services have become the de facto standard for communication among applications. J2EE 1.4 allows stateless Enterprise JavaBeans (EJB) components to be exposed as Web services via a JAX-RPC (Java API for XML Remote Procedure Call) endpoint, al
|
Building Highly Scalable Servers with Java NIO
Building Highly Scalable Servers with Java NIO
I/O Event Handling
The I/O architecture of our router was strongly inspired by the Swing event-dispatch model. In Swing, events generated by the user interface are received by the JVM and stored in an even
|
JLisa - A Rule Engine for Java
JLisa is a powerful framework for building business rules accessible to Java and it is compatible with JSR94 V, the JavaTM Rule Engine API
JLisa is more powerful than Clips because it has the expanded benefit of having all the features from common lisp a
|
Overview of Servlets and JSP
Servlets are Java technology's answer to CGI programming. They are programs that run on a Web server and build Web pages. Building Web pages on the fly is useful (and commonly done) for a number of reasons.
|
Servlets and JavaServer Pages (JSP) : A Tutorial
An excellent tutorial on JSP and Servlets.
|
Building Java Server Pages
A detailed look at building JSP pages. Should you use JSP or servlets? It mainly depends on the ratio of markup to code. Here you'll also find a guide to the different varieties of tag, and details about the main tags such as and |
Java Resources
There are all Java freebies. Some of these are old, and not under maintenance. Download and use them at your risk. In case of queries, mail subrahmanyam_avb@technologist.com or varalakshmi_a@techie.com.
|
Building Web Application With Ant and Deploying on Jboss 3.0
This lesson shows you how to build you web application and install on the Jboss 3.0 application server. After the completion of this lesson you will be able to compile, assemble and deploy your J2EE application on Jboss 3.0 application server
|
Introduction to Servlets, JSP, and Servlet Engines
Servlets are the Java Technologies' answer to CGI programming. They are programs which run on the server side and generate dynamic content. Why would one prefer to use Servlets over traditional CGI programming?
|
Service Orchestration - Cornerstone for Building Service-Oriented Architecture
This Web Cast explains the Service-Oriented Architecture (SOA). Service-oriented architecture is rapidly becoming the cornerstone for enterprise infrastructure, bringing cost reductions and increasing IT and business responsiveness.
|
Understanding MIDP System Threads
Describes the multi-threaded aspects of the J2ME application environment. Understanding the interactions between systems threads, user-interface and application threads will help in avoiding MIDlet deadlock.
|
Community-Submitted Article: Hardening the Solaris 9 OS and NcFTP for an FTP Bastion Host
A BigAdmin reader writes about the build, configuration, and subsequent hardening of UNIX servers that constitute a secured FTP solution.
|
Struts, JavaServer Faces, and Java Studio Creator:
The Evolution of Web Application Frameworks Sun Microsystems' Craig McClanahan, the creator of the Apache Struts Framework, co-specification lead for JavaServer Faces 1.0, and prime architect for Sun Java Studio Creator's new release, explains all three.
|
Practically Groovy: JDBC programming with Groovy
Take your practical knowledge of Groovy one step further this month, as Andrew Glover shows you how to use GroovySql to build a simple data-reporting application. GroovySql combines closures and iterators to ease Java Database Connectivity (JDBC) programm
|
Free Web Site Hosting Services
Below is the listing of the hosting providers providing free web hosting services. These services helps you building your sites even if you have no experience in HTML writing.
Zero
|
Building Search Engine Applications Using Servlets !
Building Search Engine Applications Using Servlets !
Building Search Engine Applications Using Servlets
Please visit http://www.webappcabaret.com/javadevelopers/search to see running copy of our search engine.
Introduction
This tutorial takes
|
|
|
|
