The java.security File

property java.home expands to what weve been calling JREHOME. If you would prefer a different set of policy files to be used by default, you can edit the java.security file and change the URLs that are used. You may specify any number of URLs, but they must be numbered consecutively beginning with 1. As weve seen, users can specify any number of policy files on the command line as well. To prevent users from specifying additional policy files, set the allowSystemProperty property to false . A site that has that value set to false, removes the users .java.policy entry from this file, and makes the java.security file uneditable by end users has established a sandbox that cannot be modified by end users. Weve shown several examples of how properties can be used in policy files in order to make them more portable. If you want to disable substitution of properties, set the expandProperties property to false .

2.8 Comparison with Previous Releases

The default sandbox is essentially unchanged between 1.2 and 1.3. In 1.2, there is no prohibition against defining classes in the java package. In Java 1.1, the default sandbox is very different. The 1.1 sandbox is determined solely by the security manager installed by the Java program; although it is possible to write a security manager that allows end users and administrators to configure different security policies, few programs followed that course. For most Java applications, this meant that no security manager was ever installed, and the program ran with complete permissions. Java applets run through the appletviewer and early, 1.1−based versions of the Java Plug−in are subject to strict, nonconfigurable restrictions. Using the signing tool of 1.1 javakey , it is possible to sign Java applets; these applets can then be given permission to perform any operation. However, the 1.1−based signing infrastructure has been deprecated, and an applet signed with javakey will not be given any special permissions in Java 2. If you need to understand the 1.1 default sandbox, see Chapter 4 for a discussion of the security manager. Appendix D, shows how you can build a 1.1 application to run other Java applications with a security policy that youve written yourself.

2.9 Summary

In this chapter, we examined the bounds and adaptability of the Java sandbox. The default sandbox is set up to be administered through a series of policy files, which contain sets of explicit permissions associated with code; this association depends on where the code was loaded from andor who signed the code. In the next few chapters, well delve into the details of the sandbox and how it is implemented. Well learn how the sandbox is built up from the low−level components of the Java platform. If youre a developer, well learn how to interact with those components while preserving the sandbox model or how you can replace it altogether. And if youre just interested in security, youll learn the details of how Java achieves its goal of platform security. 40

Chapter 3. Java Language Security

The first components of the Java sandbox that we will examine are those built into the Java language itself. These components primarily protect memory resources on the users machine, although they have some benefit to the Java API as well. Hence, they are primarily concerned with guaranteeing the integrity of the memory of the machine that is hosting a program: in a nutshell, the security features within the Java language want to ensure that a program will be unable to discern or modify sensitive information that may reside in the memory of a users machine. In terms of applets, these protections also mean that applets will be unable to determine information about each other; each applet is given, in essence, its own memory space in which to operate. In this chapter, well look at the features of the Java language that provide this type of security. Well also look at how these features are enforced, including a look at Javas bytecode verifier. With a few exceptions, the information in this chapter is largely informational; because the features we are going to discuss are immutable within the Java language, there are fewer programming considerations than well find in later chapters. However, the information presented here is crucial in understanding the entire Java security story; it is very helpful in ensuring that your Java environment is secure and in assessing the security risks that Java deployment might pose. The security of the Java environment is dependent on the security of each of its pieces, and the Java language forms the first fundamental piece of that security. As we discuss the language features in this chapter, keep in mind that were only dealing with the Java language itself −− following the common thread of this book, not all security features were going to discuss apply when the language in question is not Java. If you use Javas native interface to run arbitrary C code, that C code will be able to do pretty much anything it wants to do, even when it violates the precepts outlined in this chapter.

3.1 Java Language Security Constructs

In this chapter, were concerned primarily with how Java operates on things that are in memory on a particular machine. Within a Java program, every entity −− that is, every object reference and every primitive data element −− has an access level associated with it. To review, this access level may be: private The entity can only be accessed by code that is contained within the class that defines the entity. Default or package The entity can be accessed by code that is contained within the class that defines the entity, or by a class that is contained in the same package as the class that defines the entity. protected The entity can only be accessed by code that is contained within the class that defines the entity, by classes within the same package as the defining class, or by a subclass of the defining class. public The entity can be accessed by code in any class. The notion of assigning data entities an access level is certainly not exclusive to Java; its a hallmark of many