Methods Protecting System Resources

checkPropertyAccess Font.getFont Cant get a font unless its property can be read. checkTopLevelWindow Window Windows created by untrusted classes should have an indentifying banner. public void checkPrintJobAccess Untrusted classes are not allowed access to the users printer. This is another example of a nuisance protection; you wouldnt want a rogue applet sending reams of nonsense data to your printer. This method is never actually called by the standard Java API −− its up to the platform−specific implementation of the AWT toolkit to call it. Note this doesnt prevent the user from initiating a print action from the browser −− it only prevents an applet from initiating the print action. The utility of such a check is subtle: the user always has to confirm the print dialog box before anything is actually printed at least with the popular implementations of the AWT toolkit. The only sort of scenario that this check prevents is this: the user could surf to www.EvilSite.org and then to www.sun.com; although the applets from EvilSite are no longer on the current page, theyre still active, and one of them could pop up the print dialog. The user will associate the dialog with the www.sun.com page and presumably allow it to print −− and when the EvilSite applet then prints out offensive material, the user will blame the Sun page. In order to succeed, the current protection domain must have an AWT permission with the name queuePrintJob . public void checkSystemClipboardAccess The Java virtual machine contains a system clipboard that can be used as a holder for copy−and−paste operations. Granting access to the clipboard to an untrusted class runs the risk that a class will come along, examine the clipboard, and find contents a previous program left there. Such contents might be sensitive data the new class should not be allowed to read; hence, untrusted classes are prevented from accessing the system clipboard. This restriction applies only to the system clipboard: an untrusted class can still create its own clipboard and perform its own copy−and−paste operations to that clipboard. Untrusted classes can also share non−system clipboards between them. This method is also never actually called by the Java API; its up to the platform−specific implementation of the AWT toolkit to call it. To succeed, the current protection domain must have an AWT permission of accessClipboard . public void checkAwtEventQueueAccess Similarly, the Java virtual machine contains a system event queue that holds all pending AWT events for the system. An untrusted class that had access to such a queue would be able to delete events from the queue or insert events into the queue. This protects against the same sort of scenario we saw for printing −− an applet on a previously visited page could insert events into the queue which would then be fed to an applet on the existing page. Chapter 4. The Security Manager Since this means that an untrusted class cannot get the system event queue, it is unable to call any of the methods of the EventQueue class −− specifically the postEvent and peekEvent methods. Note, however, that an applet may still post events to itself using the dispatchEvent method of the Component class. To succeed, the current protection domain must carry an AWT permission of accessEventQueue . The default security manager implementation is overridden by the Java Plug−in and appletviewer , which allow applets access to these methods but filter out events from other applet codebases. public void checkPropertiesAccess public void checkPropertyAccessString key The Java virtual machine has a set of global system properties that contains information about the user and the users machine: login name, home directory, etc. Untrusted classes are generally denied access to some of this information in an attempt to limit the amount of spying that an applet can do. As usual, these methods only prevent access to the system properties; an untrusted class is free to set up its own properties and to share those properties with other classes if it desires. To succeed, the current protection domain must carry a property permission. If a key is specified, then the name of the property permission must include the given key and have an action of read. Otherwise, the name of the property permission must be and the action must be read and write. public boolean checkTopLevelWindowObject window Java classes, regardless of whether they are trusted or untrusted, are normally allowed to create top−level windows on the users desktop. However, there is a concern that an untrusted class might bring up a window that looks exactly like another application on the users desktop and thus confuse the user into doing something that ought not be done. For example, an applet could bring up a window that looks just like a telnet session and grab the users password when the user responds to the password prompt. For that reason, top−level windows that are created by untrusted classes have some sort of identifying banner on them. Note that unlike other methods in the security manager, this method has three outcomes: if it returns true , the window will be created normally; if it returns false , the window will be created with the identifying banner. Theoretically, this method could also throw a security exception just like all the other methods of the security manager class to indicate that the window should not be created at all; no popular implementations do that. In order for this method to return true, the current protection domain must carry an AWT permission with the name showWindowWithoutWarningBanner .

4.3.6 Methods Protecting Security Aspects

There are a number of methods in the security manager that protect Javas idea of security itself. These methods are summarized in Table 4−6. Table 4−6. Security Manager Methods Protecting Java Security Method 70 Called By Rationale checkMemberAccess Class.getFields Class.getMethods Class.getConstructors Class.getField Class.getMethod Class.getConstructor Class.getDeclaredClasses Class.getDeclaredFields Class.getDeclaredMethods Class.getDeclaredConstructors Class.getDeclaredField Class.getDeclaredMethod Class.getDeclardConstructor Untrusted classes can only inspect public information about other classes. checkPackageAccess Not called Check if the untrusted class can access classes in a particular package. checkPackageDefinition Not called Check if the untrusted class can load classes in a particular package. checkSecurityAccess Identity.setPublicKey Identity.setInfo Identity.addCertificate Identity.removeCertificate IdentityScope.setSystemScope Provider.clear Provider.put Provider.remove Security.insertProviderAt Security.removeProvider Security.setProperty Signer.getPrivateKey Signer.setKeyPair Untrusted classes cannot manipulate security features. public void checkMemberAccessClass clazz, int which In Chapter 3, we examined the importance of the access modifiers to the integrity of Javas security model. Javas reflection API allows programs to inspect classes to determine the classs methods, variables, and constructors. The ability to access these entities can impact the memory integrity that Java provides. The reflection API is powerful enough that, by inspection, a program can determine the private instance variables and methods of a class although it cannot actually access those variables or call those methods. All classes are allowed to inspect any other class and find out about its public variables and methods. All classes loaded by the same class loader are allowed to inspect all of each others variables and methods. Otherwise, the current protection domain must carry a runtime permission with a name of accessDeclaredMembers . The default implementation of this method is very fragile. Unlike all other methods that well look at, it is a logical error to override this method and then call super.checkMemberAccess . public void checkSecurityAccessString action In the last half of this book, well be examining the details of the Java security package. This package implements a higher−order notion of security, including digital signatures, message digests, public and private keys, etc. The security package depends on this method in the security manager to arbitrate which classes can perform certain security−related operations. As an example, before a class is allowed to read a private key, this method is called with a string indicating that a private key is being read. Predictably, only trusted classes are allowed to perform any of these security−related operations. Although the string argument gives the ability to distinguish what operation is being attempted, that argument is typically ignored in present implementations. As we discuss the features of the security package itself, well examine how the security package uses this method in more depth. public void checkPackageAccessString pkg public void checkPackageDefinitionString pkg These methods are used in conjunction with a class loader. When a class loader is asked to load a class with a particular package name, it will first ask the security manager if it is allowed to do so by calling the checkPackageAccess method. This allows the security manager to make sure that the untrusted class is not trying to use application−specific classes that it shouldnt know about. Similarly, when a class loader actually creates a class in a particular package, it asks the security manager if it is allowed to do so by calling the checkPackageDefinition method. This allows the security manager to prevent an untrusted class from loading a class from the network and placing it into, for example, the java.lang package. Notice the distinction between these two methods: in the case of the checkPackageAccess method, the question is whether the class loader can reference the class at all −− e.g., whether we can call a class in the sun package. In the checkPackageDefinition method, the class bytes have been loaded and the security manager is being asked if they can belong to a particular package. By default, the checkPackageDefinition method is never called and the checkPackageAccess method is called only for packages listed in the package.access property within the java.security file. If you write a class loader, you may call it as we indicate in Chapter 6. To succeed, the current protection domain must have a runtime permission with the name defineClassInPackage.+pkg or accessClassInPackage.+pkg . 72