Managing permissions The policytool

in the core API; if you need to add a permission in an extension or a third−party package, you must enter the type explicitly. When you select a type, the pulldown for the permission target name changes to match valid names for the type. However, since many types accept arbitrary names, you often need to type the target name explicitly into the box; for example, when you select a socket permission, you must type the hostname andor port name explicitly. Even though policytool provides an administrative GUI for policy files, you still must be very familiar with the names of permissions as well as the targets and actions they accept.

2.5.2 Permissions Outside of Policy Files

Virtually all of the permissions granted to code comes from policy files. However, advanced applications are allowed to grant additional permissions to code that they load, and standard Java class loaders grant some additional permissions to every class that they load. Classes that are loaded from the filesystem are always granted permission to read files in the directory hierarchy from which they were loaded. Classes that are loaded via HTTP are always granted permission to establish a connection back to the host from which they were loaded; they are also granted permission to accept a connection from that host.

2.6 The Default Sandbox

And now, putting this all together, lets examine the default sandbox of various Java environments: Java applications For applications invoked via the Java command line, the sandbox is initially disabled. To enable the sandbox, you must specify the java.security.manager property like this: piccolo java −Djava.security.manager other args Applications may also enable the sandbox programatically by installing a security manager, as we discuss in Chapter 4. Once enabled, the security manager will use the two default policy files to determine the parameters of the sandbox. You can specify an additional policy file to be used with the java.security.policy property: piccolo java −Djava.security.policy=URL You can specify a full URL e.g., with an http: or file: protocol or simply list a filename. If you want the given policy file to be the only policy file used bypassing the ones in JREHOMElibsecurity and the users home directory, specify two equals signs: piccolo java −Djava.security.policy==URL Putting this all together, heres how we would run the class PayrollApp in the default sandbox with additional permissions loaded from the file java.policy in the local directory: piccolo java −Djava.security.manager \ −Djava.security.policy=java.policy PayrollApp Appletviewer Chapter 2. The Default Sandbox The appletviewer installs a security manager programatically; it cannot be disabled. It will use the standard policy files; to use additional policy files, specify the appropriate policy argument with the −J argument: piccolo appletviewer −J−Djava.security.policy=URL Although it obeys the default rules for accessing classes in packages via the accessClassInPackage permission discussed earlier, the appletviewer also allows you to restrict or allow access to classes in the sun package through a special property file. That property is set in the appletviewer properties menu. The Java Plug−in The Java Plug−in installs a security manager programatically; it cannot be disabled. It will use the standard policy files; to use additional policy files, you must use the Java Plug−in Control Panel. On the advanced tab of that panel, you can specify the desired java.security.policy argument. The Java Plug−in supports an alternate sandbox. This sandbox is used whenever the Plug−in runs an applet that has been signed. When the Plug−in encounters a signed jar file, it will present a dialog box to the user. The user has the option of giving the signed code permission to perform any operation for this session only or anytime it runs code signed by the given organization. Otherwise, the code will run with normal permissions based on its codebase and the permissions in the relevant policy files. This is the model used by Netscape 6 as well since Netscape 6 uses the Java Plug−in for all applets. Other Java−enabled browsers Older versions of Netscape and all versions of Internet Explorer define their own sandbox. Those sandboxes are completely unrelated to the policy−based model weve discussed here. They provide the same restrictions that we have discussed in this chapter applets cannot read files, can only open sockets back to the host from which they were loaded, have limited property permissions, and no other permissions; its simply that you cannot modify the sandbox administratively. These browsers do allow code to be signed, in which case the user can optionally grant the code permission to perform many operations. In addition, they allow developers to ask for particular operations to be performed using proprietary APIs. Check with the browser vendor for more details.

2.6.1 The Default Policy File

One way or another, the three common Java environments will use the same policy files to determine the parameters of the sandbox. By default, users do not have a .java.policy file in their home directory, which means that the default set of permissions for all Java programs running in the sandbox is defined by the JREHOMElibsecurityjava.policy file. Here are the contents of that file in 1.3: Installed extensions are granted all permissions grant codeBase file:{java.home}libext { permission java.security.AllPermission; }; All code is allowed the following permissions grant { Anyone can call Thread.stop , though only for