One of the most important features of Java is its security model.It allows untrusted code, such as applets downloaded fromarbitrary web sites, to be run in a restricted environment thatprevents that code from doing anything malicious, like deletingfiles or sending fake email. The Java security model has evolvedconsiderably between Java 1.0 and Java 1.2 and is covered indetail in Java in a Nutshell.
To write applets, you don‘t need to understand the entire Javasecurity model. What you do need to know is that when your appletis run as untrusted code, it is subject to quite a fewsecurity restrictions that limit the kinds of things it can do.This section describes those security restrictions and alsodescribes how you can attach a digital signature to applets, sothat users can treat them as trusted code and run them in a lessrestrictive environment.
The following list details the security restrictions that aretypically imposed on untrusted applet code. Different webbrowsers and applet viewers may impose slightly different securityrestrictions and may allow the end user to customize orselectively relax the restrictions. In general, however, youshould assume that your untrusted applet are restricted in thefollowing ways:
Untrusted code cannot read from or write to the local filesystem. This means that untrusted code cannot:
Read files
List directories
Check for the existence of files
Obtain the size or modification date of files
Obtain the read and write permissions of a file
Test whether a filename is a file or directory
Write files
Delete files
Create directories
Rename files
Read or write from FileDescriptor objects
Untrusted code cannot perform networking operations, except in certain restricted ways. Untrusted code cannot:
Create a network connection to any computer other than the one from which the code was itself loaded
Listen for network connections on any of the privileged ports with numbers less than or equal to 1,024
Accept network connections on ports less than or equal to 1,024 or from any host other than the one from which the code itself was loaded
Use multicast sockets
Create or register a SocketImplFactory, URLStreamHandlerFactory, or ContentHandlerFactory
Untrusted code cannot make use of certain system facilities. It cannot:
Exit the Java interpreter by calling System.exit() or Runtime.exit()
Spawn new processes by calling any of the Runtime.exec() methods
Dynamically load native code libraries with the load() or loadLibrary() methods of Runtime or System
Untrusted code cannot make use of certain AWT facilities. One major restriction is that all windows created by untrusted code display a prominent visual indication that they have been created by untrusted code and are "insecure." This is to prevent untrusted code from spoofing the on-screen appearance of trusted code. Additionally, untrusted code cannot:
Initiate a print job
Access the system clipboard
Access the system event queue
Untrusted code has restricted access to system properties. It cannot call System.getProperties(), so it cannot modify or insert properties into the system properties list. It can call System.getProperty() to read individual properties but can read only system properties to which it has been explicitly granted access. By default, appletviewer grants access to only the following 10 properties. Note that user.home and user.dir are excluded:
java.version
java.class.version
java.vendor
java.vendor.url
os.name
os.version
os.arch
file.separator
path.separator
line.separator
Untrusted code cannot create or access threads or thread groups outside of the thread group in which the untrusted code is running.
Untrusted code has restrictions on the classes it can load and define. It cannot:
Explicitly load classes from the sun.* packages
Define classes in any of the java.* or sun.* packages
Create a ClassLoader object or call any ClassLoader methods
Untrusted code cannot use the java.lang.Class reflection methods to obtain information about nonpublic members of a class, unless the class was loaded from the same host as the untrusted code.
Untrusted code has restrictions on its use of the java.security package. It cannot:
Manipulate security identities in any way
Set or read security properties
List, look up, insert, or remove security providers
Finally, to prevent untrusted code from circumventing all of these restrictions, it is not allowed to create or register a SecurityManager object.
When an applet is loaded from the local filesystem, instead ofthrough a network protocol, web browsers and applet viewers mayrelax some, or even many, of the preceding restrictions. The reasonfor this is that local applets are assumed to be moretrustworthy than anonymous applets from the network.
Intermediate applet security policies are also possible. Forexample, an applet viewer can be written so that it placesfewer restrictions on applets loaded from an internal corporatenetwork than on those loaded from the Internet.
Java 1.1 added the ability to attach a digital signature to a JARfile that contains an applet. This signature securely identifiesthe author or origin of an applet. If you trust the author ororiginating organization, you can configure your web browser orapplet viewer to run applets bearing that signature as trustedcode, rather than as untrusted code. Such an applet runswithout the onerous security restrictions placed on untrustedapplets. Java 1.2 platform actually allows the security policy to becustomized based on the origin of an applet. This means that anend user or system administrator may define multiple levels oftrust, allowing fully trusted applets to run with all theprivileges of a standalone application, whilepartially trusted applets run with a reduced list of securityrestrictions.
The process of attaching a digital signature to an applet‘s JARfile is platform dependent. In Java 1.1, you use thejavakey program. In Java 1.2, this programhas been superseded by jarsigner. Netscapeand Microsoft also provide their own digital signature programsthat are customized for use with their browsers.
The process of telling your web browser or applet viewer whichdigital signatures to trust is also vendor dependent, of course.In Java 1.1, you use javakey to specifywhich signatures are trusted. In Java 1.2, you use a differenttool, policytool, to specify trustedsignatures and the security policiesassociated with them. See Java in aNutshell for further details.
聯(lián)系客服
