Java security evolution
and concepts, Part 3: Applet security
- JavaWorld
December 2000
Tutorial Details:
Java security evolution and concepts, Part 3: Applet security
Java security evolution and concepts, Part 3: Applet security
By: By Raghavan N. Srinivas
Tackle Java applet security with confidence
ava's early growth was spurred by code downloadable over a network, better know as applets. Applet security has evolved with the growth of Java, and today is a source of frequent confusion due to the variety of Java versions, commercially available browsers, and plug-ins.
This article, the third in the series, will cover the various requirements for securely running Java code downloaded from a network. Although mobile code is not a revolutionary concept, Java and the Internet present some unique challenges to computer security. The evolution of the Java architecture and its impact on core Java security was discussed in Parts 1 and 2. This article takes a different tack: a hands-on approach to tie all the concepts together by deploying a simple applet that writes to the local filesystem.
Java security evolution and concepts: Read the whole series!
Part 1: Learn computer security concepts and terms in this introductory overview
Part 2: Discover the ins and outs of Java security
Part 3: Tackle Java applet security with confidence
Part 4: Learn how optional packages extend and enhance Java security
Part 5: J2SE 1.4 offers numerous improvements to Java security
At the example applet's core is public-key cryptography, introduced earlier in this series. Code signed using the private key of the signer can be run on client machines once the public key corresponding to the signer is deemed as trusted on the respective machine. We'll also discuss how policy files, which accord permissions and keystore, can be used as a repository for public and private keys. Moreover, we'll highlight the Java 2 SDK security tools and Netscape's signtool , since they enable deployment.
This article traces the evolution of Java security, beginning with application security in the initial release of Java 2 and moving on to the latest version of Java 2, version 1.3. This approach helps introduce the concepts gradually, starting with very simple concepts and culminating in a fairly advanced example.
This series does not intend to provide a comprehensive guide to computer security. Computer security is a multifaceted issue touching several disciplines, departments, and cultures. Investments in technologies should be followed up with investments in personnel training, strict enforcement of policies, and periodic review of the overall security policy.
Note: This article features a running Java applet designed to demonstrate applet security issues. Read below for more details.
Application security
Let's begin our investigation by looking at application security. In Part 2 we saw how Java security has evolved from a sandbox model to a fine-grained security model. We also saw that applications (local code) by default get a free reign and are not subject to the same control as applets (network-downloadable code), which are typically deemed as untrusted. In a change from the past, in Java 2 security applications can be optionally subject to the same level of control as applets.
First, a quick note about writeFile.java , the code used in this article to illustrate the security features in Java 2. This program is a slightly modified version of the applet code provided by Sun, available over the Web to illustrate some of the features of Java 2 security. The program, modified to provide application support, attempts to create and write a file on the local filesystem. Access to a local filesystem is screened by the security manager. We will see throughout this article how this particular operation can be permitted in a secure manner.
/**
* By default, this raises a security exception as an applet.
*
* With JDK 1.2 appletviewer,
* if you configure your system to grant applets signed by "Duke"
* and downloaded from the Java Software Website to write a file
* to your /tmp directory (or to the file named "C:\tmpfoo" on a
* Windows system), then this applet can run.
*
* @version JDK 1.2
* @author Marianne Mueller
* @Modified by Raghavan Srinivas[Rags]
*/
import java.awt.*;
import java.io.*;
import java.lang.*;
import java.applet.*;
public class writeFile extends Applet {
String myFile = "/tmp/foo";
File f = new File(myFile);
DataOutputStream dos;
public void init() {
String osname = System.getProperty("os.name");
if (osname.indexOf("Windows") != -1) {
myFile="C:" + File.separator + "tmpfoo";
}
}
public void paint(Graphics g) {
try {
dos = new DataOutputStream(new BufferedOutputStream(new FileOutputStream(myFile),128));
dos.writeBytes("Cats can hypnotize you when you least expect it\n");
dos.flush();
dos.close();
g.drawString("Successfully wrote to the file named " + myFile + " -- go take a look at it!", 10, 10);
}
catch (SecurityException e) {
g.drawString("writeFile: caught security exception", 10, 10);
}
catch (IOException ioe) {
g.drawString("writeFile: caught i/o exception", 10, 10);
}
}
public static void main(String args[]) {
Frame f = new Frame("writeFile");
writeFile writefile = new writeFile();
writefile.init();
writefile.start();
f.add("Center", writefile);
f.setSize(300, 100);
f.show();
}
}
Running the bytecode generated in a Java 2 Runtime Environment, Standard Edition (JRE) will let the application modify the file on the local filesystem by default, since the default policy does not subject Java 2 applications to a security manager. This policy is justified because applications are typically locally generated code and not downloaded over the network. The following command line produces the window shown in Figure 1, indicating that the file was created and written into.
$ java writeFile
Figure 1. writeFile Application -- no security manager
To subject the code to the Java 2 security manager, invoke the following command line, which should produce the results indicated in Figure 2. Notice that the application generated a security exception caused by an attempt to modify the local filesystem. The explicitly included security manager generated the exception.
$ java -Djava.security.manager writeFile
Figure 2. writeFile Application -- including the security manager
The cases illustrated above represent extreme examples of security policy. In the former case, the application was not subject to any control; in the latter, it was subject to a very rigid control. In most cases it will be necessary to set the policy somewhere in between.
You can accomplish an in-between policy using a policy file. To do so, create a policy file called all.policy in the working directory:
grant {
permission java.io.FilePermission "<>", "write";
};
Running the same piece of code with the following command line will allow modification of the local filesystem:
$ java -Djava.security.manager -Djava.security.policy=all.policy writeFile
In this example, the application was subject to the security manager, but the overall policy was governed by the policy file, which allowed all files on the local filesystem to be modified. A stricter policy might have been to allow modification of only the relevant file -- tmpfoo in this case.
I'll cover more details of the policy file, including the syntax of the entries, later in this article. But first, let's look at applet security and contrast it with application security.
Applet security
So far, we've studied application security. As such, most of the security features can be accessed and modified via the command line. Providing an adequately secure and yet somewhat flexible policy in an applet environment proves substantially more challenging. We will start by looking at the deployment of an applet in Appletviewer . We'll look at browser-deployed applets later.
Java code policy is primarily dictated by CodeSource , which comprises two pieces of information: the place where the code originated and the person who signed it.
Appletviewer
Create a file called writeFile.html with the following contents:
Java Security Example: Writing Files
Java Security Example: Writing Files
Running the applet with the following command line would result in the window shown in Figure 3:
$ appletviewer writeFile.html
Figure 3. appletviewer -- applets subject to security manager by default
Notice that -- in contrast to what would happen with an application -- the applet generated an exception since the applet is subject to the security manager by default. The installation can be governed by a customizable policy, if required. Running the following command line:
appletviewer -J"-Djava.security.policy=all.policy" writeFile.html
would, as you might expect, allow modification of the tmpfoo file, since this was permitted in accordance with the policy file.
Browsers
Applet security in browsers strives to prevent untrusted applets from performing potentially dangerous operations, while simultaneously allowing optimal access to trusted applets. Applet security deployment in browsers is substantially different from what we have seen so far, primarily due to the following reasons:
A default lack of trust in code downloaded over the network
Insufficient access to the command-line options for running the JVM, since the JVM is hosted in the context of a browser
Inadequate support for some of the latest security features in the JVMs bundled with browsers
As for the first problem, to obviate the potential problems resulting from running untrusted code, earlier versions of Java used the sandbox model (see " Sidebar 1: Sandbox Model "). Trust is a largely philosophical or emotional issue, rather than a technical issue; however, technology can help. For example, Java code can be signed using certificates. In this example, the signer implicitly vouches f
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Java security evolution
and concepts, Part 3: Applet security
- JavaWorld
December 2000
View Tutorial: Java security evolution
and concepts, Part 3: Applet security
- JavaWorld
December 2000
Related
Tutorials:
 Integrate security infrastructures with JBossSX
Integrate security infrastructures with JBossSX
|
Java security evolution
and concepts, Part 2
Java security evolution
and concepts, Part 2
|
Java security evolution
and concepts, Part 4
Java security evolution
and concepts, Part 4
|
Java security evolution
and concepts, Part 5
Java security evolution
and concepts, Part 5
|
I want my AOP!, Part 1
I want my AOP!, Part 1
|
Step into
the J2EE architecture and process
Step into
the J2EE architecture and process
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Yes, you can secure your Web services documents, Part 1
Yes, you can secure your Web services documents, Part 1
|
Should you go
with JMS?
Should you go
with JMS?
|
Check out three
collections libraries
Check out three
collections libraries
|
Jini Starter Kit 2.0 tightens Jini's security framework
Jini Starter Kit 2.0 tightens Jini's security framework
|
Java and Security, Part 1
Java and Security
WebLogic provides a comprehensive suite of security services that can be used to protect all aspects of a domain and its deployments. These security services affect all aspects of your domain: from the lowest level provided by the Jav
|
Java and Security, Part 2
Java and Security
The Providers
Now we\'ll take a closer look at the different SSPIs that constitute a security realm. We\'ll learn about WebLogic\'s default implementation of these security providers and how to configure them. The default implementat
|
J2EE security: Container versus custom
Choose the appropriate type of security for your application
Summary
This article covers the factors to consider when choosing between custom J2Esecurity and E standard security, also known as container security. It briefly covers how each type of secu
|
jGuard v0.60 released!
jGuard v0.60 released!
i am pleased to announce a new major release(v0.60) of the java security library called jGuard(http://sourceforge.net/projects/jguard/).
this library is build on top of jaas, for J2EE web applications.
his goal is to provide f
|
Using SSL with Non-Blocking IO
Using SSL with Non-Blocking IO
After the initial experiments with Java NIO, most developers start wondering about security; in particular, how to use SSL with Java NIO. With the traditional blocking sockets API, security is a simple issue: just set up an
|
JavaTM Secure Socket Extension (JSSE)
The JavaTM Secure Socket Extension (JSSE) is a Java package that enables secure Internet communications. It implements a Java version of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols and includes functionality for data encryption
|
Chat Transcript: Java Web Services Developer Pack (Java WSDP) 1.5
Learn about the exciting new web services features in the recently-released Java WSDP 1.5.
|
Using Identity Management to Achieve Security and Compliance: White Paper (pdf)
As described in this white paper, identity management can play a significant role in enabling organizations to meet demands for security and compliance.
|
Integrating Java Open Single Sign-On in Pluto
This article shows how to integrate Java Open Single Sign-On in Apache\'s Pluto portlet container.
|
|
|
|
