Java security evolution
and concepts, Part 2
Tutorial Details:
Java security evolution and concepts, Part 2
Java security evolution and concepts, Part 2
By: By Raghavan N. Srinivas
Discover the ins and outs of Java security
ne of Java's main features is its ability to move code over a network and run that code. Unlike other languages, Java has been designed to do this securely. Java security has evolved over time; recent releases provide fine-grained security features that enable implementation of a flexible policy decoupled from the implementation mechanism.
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
This article, Part 2 of a series, will cover the various aspects of 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 security, different security APIs and tools, and applet security will be covered in this series.
This is not intended to be a comprehensive guide to computer security, a multifaceted issue encompassing several disciplines, departments, and cultures. Investments in security technologies should be followed by investments in personnel training, strict enforcement of policies, and periodic review of the overall policy.
Language vis-a-vis runtime security
Although enforcement of policies during code execution is a substantial part of security, proper security starts at the very beginning, during the generation of byte code. A language's type safety, which is enforced by the compiler and checked by the runtime environment, proves critical to an overall secure environment. Many of computing's earliest security breaches stemmed from the ability to easily overflow buffers or access memory unimpeded, situations caused in part by a language's poor type safety and inadequate enforcement in the executing environment.
Java security manifests itself in the following forms: protection built into the language, building blocks for a flexible secure environment, and protection against accidental or malicious attacks to the language and platform. Simply put, Java security should ensure that the specifications for the language and virtual machine (VM) are followed.
Despite the safety checks enforced by the compiler, the VM must still be able to deal with faulty byte code, whether generated accidentally or maliciously. Below, we'll examine the enforcement of runtime checks during execution and the evolution of the runtime environment to support the design of a very flexible security policy.
As for language security inherent in the language's design, Java's design was heavily influenced by C and C++ -- particularly their weaknesses. Consequently, the Java compiler generates warnings for uninitialized variables. The language itself is strongly typed, with many unsafe constructs omitted or modified; for example, array accesses are done with index checking. Moreover, because memory deallocation in Java is the garbage collector's responsibility rather than the programmer's, Java avoids many common programming errors in C and C++ caused by faulty memory deallocation. Finally, the compiler enforces exception-catching. This discipline of catching and fixing potential errors may not have direct security implications. However, an unhandled error might lead to unpredictable behavior, which, from a security standpoint, should be avoided.
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.
Figure 4. Java 2 security architecture
Byte-code verifier
Since Java code can be imported from anywhere in the network, it is critical to screen the code to be sure that it was produced by a trustworthy compiler. The byte-code verifier, sometimes referred to as a mini-theorem prover, tries to prove that a given series of Java byte codes are legal.
Among other things, it verifies the format of the class file - it must have the right length, the correct magic numbers, no operand stack overflows and underflows, and so on. In short, the verifier confirms or denies that the class file is consistent with the specifications. Although Figure 4 appears to indicate that byte-code verification occurs when the class is loaded, some of these checks may be delayed until just before the byte code is first executed.
Even though the byte-code verifier serves an important purpose, it is not very interesting from a programming standpoint because its behavior cannot be altered programmatically. The behavior may be altered with command line options on the interpreter, when applicable.
ClassLoader
The ClassLoader, which loads Java byte codes into the JVM, is an important link in the security chain. It works in conjunction with the SecurityManager and the access controller to enforce security rules. Notice in Figure 4 that the ClassLoader is involved in enforcing some security decisions earlier in an object's lifetime than the security manager. Also, information about the URL from which the code originated and the code's signers is initially available to the ClassLoader.
It is possible to implement a customized ClassLoader or a subclass from java.security.SecureClassLoader to provide security features beyond those offered by the standard Java 2 Security model.
The ClassLoader, as its name indicates, loads classes into the VM. It is also responsible for the concept of namespaces at runtime, which are created by packages. With namespaces, identically named identifiers can refer to different objects.
Since a ClassLoader is itself a class, some bootstrapping is necessary early on. The ClassLoader, referred to as the primordial class loader and usually written in a native language, loads the bootstrap classes in a platform-dependent manner.
Some classes defined in the java.* package are essential to the JVM and the runtime system. These are referred to as system classes, loaded by the System ClassLoader. The terminology sometimes extends to all classes found in the CLASSPATH environment variable. Typically, a ClassLoader hierarchy is created as more classes are loaded.
CodeSource
Since Java code can be downloaded over a network, the code's origin and author are critical to maintaining a secure environment. Consequently, the object java.security.CodeSource fully describes a piece of code. The CodeSource encapsulates the code's origin, which is specified as an URL, and the set of digital certificates containing public keys corresponding to the set
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Java security evolution
and concepts, Part 2
View Tutorial: Java security evolution
and concepts, Part 2
Related
Tutorials:
 Create forward-compatible beans in EJB,
Part 2 - JavaWorld January
2000
Create forward-compatible beans in EJB,
Part 2 - JavaWorld January
2000
|
Java security evolution
and concepts, Part 1: Security nuts and bolts - JavaWorld April
2000
Java security evolution
and concepts, Part 1: Security nuts and bolts - JavaWorld April
2000
|
Java security evolution
and concepts, Part 3: Applet security
- JavaWorld
December 2000
Java security evolution
and concepts, Part 3: Applet security
- JavaWorld
December 2000
|
Breathe intelligence into Java - JavaWorld April 2001
Breathe intelligence into Java - JavaWorld April 2001
|
Secure your
Java apps from end to end, Part 1 - JavaWorld June 2001
Secure your
Java apps from end to end, Part 1 - JavaWorld June 2001
|
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
|
All that JAAS
All that JAAS
|
Should you go
with JMS?
Should you go
with JMS?
|
The Java Web Services Tutorial
This tutorial is a beginner\'s guide to developing Web services and Web applications using the Java Web Services Developer Pack (Java WSDP).
|
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
|
Attribute-Oriented Programming with Java 1.5, Part 2
Peeking Inside the Box: Attribute-Oriented Programming with Java 1.5,Part
In the previous article in this series, "Peeking Inside the Box, Part 1," I introduced the concepts of Attribute-Oriented Programming, Java 1.5 annotations, and bytecode instrume
|
The ABCs of Synchronization, Part 1
Threads may execute in a manner where their paths of execution are completely independent of each other. Neither thread depends upon the other for assistance. For example, one thread might execute a print job, while a second thread repaints a window. And
|
The JavaTM Web Services Tutorial
A beginner's guide to developing Web services and Web applications on the Java Web Services Developer Pack
|
Open Source Web Frameworks in Java
Open Source Web Frameworks in Java
Open Source Web Frameworks in Java
Struts
Struts Frame work is the implementation of Model-View-Controller (MVC) design pattern for the JSP. Struts is maintained as a part of Apache Jakarta project and is open
|
|
|
|
