The Default Policy File

backward compatibility. permission java.lang.RuntimePermission stopThread; allows anyone to listen on unprivileged ports permission java.net.SocketPermission localhost:1024−, listen; standard properies that can be read by anyone permission java.util.PropertyPermission java.version, read; permission java.util.PropertyPermission java.vendor, read; permission java.util.PropertyPermission java.vendor.url, read; permission java.util.PropertyPermission java.class.version, read; permission java.util.PropertyPermission os.name, read; permission java.util.PropertyPermission os.version, read; permission java.util.PropertyPermission os.arch, read; permission java.util.PropertyPermission file.separator, read; permission java.util.PropertyPermission path.separator, read; permission java.util.PropertyPermission line.separator, read; permission java.util.PropertyPermission java.specification.version, read; permission java.util.PropertyPermission java.specification.vendor, read; permission java.util.PropertyPermission java.specification.name, read; permission java.util.PropertyPermission java.vm.specification.version, read; permission java.util.PropertyPermission java.vm.specification.vendor, read; permission java.util.PropertyPermission java.vm.specification.name, read; permission java.util.PropertyPermission java.vm.version, read; permission java.util.PropertyPermission java.vm.vendor, read; permission java.util.PropertyPermission java.vm.name, read; }; By default, installed extensions can perform any operation. All other code is allowed to call Thread.stop , to listen on an unprivileged port, and to read a limited set of system properties. And thats it: no file access, no other socket access, and so on other than the file and socket access granted to all files that we mentioned earlier. Even the ability to listen on an unprivileged port is of dubious value: in order to complete a socket connection, the program is required to accept a connection from a particular IP address. The accept permission is not granted in this file; it must be enabled elsewhere in order for a program to open a server socket.

2.7 The java.security File

Many parameters of the default sandbox are controlled by entries in the java.security file. This file JREHOMElibsecurityjava.security can be edited by system administrators, which is particularly effective when it is shared by several end users though end users, of course, can administer it themselves if required. That file has several entries that well examine throughout this book; an annotated version of it appears in Appendix A. In terms of the default sandbox, here are the important entries: policy.expandProperties=true policy.allowSystemProperty=true policy.url.1=file:{java.home}libsecurityjava.policy policy.url.2=file:{user.home}.java.policy When we say that there are two default policy files, its because of the entries in this file note that the Java Chapter 2. The Default Sandbox 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