|
|
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
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!
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.
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.
writeFile.java source file, associated with this article, go tosigntool