Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java security evolution and concepts, Part 2

Discover the ins and outs of Java security

By Raghavan N. Srinivas, JavaWorld.com, 07/28/00

Page 2 of 6

Evolution of Java security

Some security features touted in recent Java releases were also available in earlier versions. However, using them involved a considerable amount of additional programming and a good understanding of the security model. Generally, Java has provided access to the language and the runtime environment conservatively, which is good from a security perspective, although somewhat restrictive of the ability to support different policies.

It's necessary for a security designer to understand Java security evolution, as many enterprises may have to support pre-Java-2 releases for years to come. So this article will concentrate on Java 2 Security, but only after an overview of security in previous releases.

JDK 1.0 security -- Java security hits the sandbox

JDK 1.0 featured the sandbox security model, as seen in Figure 1. The sandbox model confines Java applets, potentially dangerous or not, to a strictly defined arena where they cannot affect other system resources. (For more details of the sandbox model, including its limitations, see the "Sidebar 1: Sandbox model for security.")

Figure 1. JDK 1.0 security
model -- the sandbox
Click on thumbnail
to view full image (20 KB)

Since applications load locally, they, unlike applets, need not be deemed untrustworthy and enjoyed unlimited access to all resources in JDK 1.0. A consistent security policy for applets and applications was therefore not supported by this model.

JDK 1.1 Security -- all or nothing

JDK 1.0's sandbox model provided virtually no flexibility. In an attempt to overcome this, JDK 1.1 introduced the signed applet, illustrated in Figure 2. A signed applet is an applet packaged as a Java Archive (JAR) file and signed with a private key. The signed applet enjoys unlimited access, just like a local application, provided the corresponding public key is trusted in the executing environment. Unsigned applets default back to the sandbox model.

Figure 2. The JDK 1.1 security model
Click on thumbnail
to view full image (24 KB)

JDK 1.1's security model was less restrictive than the sandbox model and provided for slightly more consistent treatment of applets and applications. However, it had one major disadvantage: applets either received unlimited access or were confined to the sandbox -- there was no option for selective access to resources. This model was another example of an inflexible implementation where the policy was forced by the mechanism.

Java 2 Security -- fine-grained security

The Java 2 Security model, as illustrated in Figure 3, provides for a consistent and flexible policy for applets and applications. While applications still run unrestricted by default, they can be subjected to the same policy as applets.

The Java 2 model also introduces the concept of a ProtectionDomain, which permits a highly flexible security policy decoupled from its implementation.

Figure 3. Java 2 Security model
Click on thumbnail
to view full image (28 KB)

Overview of Java 2 security

The various features of the Java 2 Runtime Environment's security model can be seen in Figure 4. As a general caveat, some of the issues discussed might not be part of the specification per se, but still peculiar to most implementations.