Methods Protecting System Resources

The Java−enabled browser has access to certain system−level resources to which untrusted classes should not be granted access. The next set of methods (outlined in Table 4−5) in the SecurityManager class handles

those system−level resources.

Table 4−5. Security Manager Protections of System Resources

Method Called By

Rationale

checkPrintJobAccess( ) Toolkit.getPrintJob( )

Untrusted classes can't initiate print jobs.

checkSystemClipboardAccess( ) Toolkit.getSystemClipboard( )

Untrusted classes can't read the system clipboard.

checkAwtEventQueueAccess( ) EventQueue.getEventQueue( )

Untrusted classes can't manipulate window events.

checkPropertiesAccess( )

System.getProperties( ) System.setProperties( )

Untrusted classes can't see or set system properties.

checkPropertyAccess( )

System.getProperty( )

Untrusted classes can't get a particular system property.

checkPropertyAccess( ) Locale.setDefault( )

Can't change the locale unless the user.language property can be read.

checkPropertyAccess( ) Font.getFont( )

Can't 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 user's printer. This is another example of a nuisance protection; you wouldn't want a rogue applet sending reams of nonsense data to your printer. This method is never actually called by the standard Java API −− it's up to the platform−specific implementation of the AWT toolkit to call it.

Note this doesn't 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, they're 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; it's 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.

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 checkPropertyAccess(String key)

The Java virtual machine has a set of global (system) properties that contains information about the user and the user's 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 checkTopLevelWindow(Object window)

Java classes, regardless of whether they are trusted or untrusted, are normally allowed to create top−level windows on the user's desktop. However, there is a concern that an untrusted class might bring up a window that looks exactly like another application on the user's 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 user's 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.