AWT permissions The Types of Permissions

File permissions Network permissions Socket permissions Property permissions Reflection permissions Runtime permissions Security permissions Serializable permissions Each of these permission types defines a specific way in which the sandbox can be breached. For a typical RMI application, the four most important types are AWT permissions, file permissions, socket permissions, and property permissions. In the following subsections, we will discuss each of these four permission types in more detail. In the discussion that follows, I will also give examples illustrating how each permission is assigned; the syntax of the examples and how the associated permissions are actually passed to the JVM will be explained later in Sect ion 20.4 .

20.2.1.1 AWT permissions

AWT permissions control access to resources associated with the screen. This type of permission was created in response to three possible security breaches: Fooling the user A hostile piece of code could pretend to be a friendly piece of code. For example, it could pop up a registration wizard sequence of dialog boxes that, under the guise of helping the user with her software, captured personal information. Capturing static information Alternatively, the hostile code could simply look at the clipboard, or capture whats on the screen. For example, hostile code downloaded into an email client could conceivably simply create GIF images of text windows and send them off for analysis. Fooling the running application The third security breach involves mimicking the user. Java 2 includes a new mechanism, called the robot, which simulates user actions. While primarily intended for automated user-interface testing, the events generated via the robot mechanism are indistinguishable from actual user actions. Because there are a variety of different security breaches involved, there are six subtypes of the AWT permission: accessClipBoard , accessEventQueue , listenToAllAwtEvents , readDisplayPixels , showWindowWithoutWarningBanner , and createRobot . They are all boolean values™a piece of code either has permission to perform the operation or it does not. Heres a permissions example granting all classes the ability to show windows without warning banners: grant { permission java.awt.AWTPermission showWindowWithoutWarningBanner; }; Unless this permission is granted, an application window will be displayed with an applet warning banner across the bottom, as in Figur e 20- 1 . Figure 20-1. Applet window with warning banner These apply even if you arent using AWT directly. For example, if you are using Swing components to build your GUI, the AWT permissions still apply since Swing is implemented as a layer on top of AWT.

20.2.1.2 File permissions