JavaTM Security Architecture (JDK1.2) 6. Security Management 6.1 Managing Applets and Applications
Currently, all JDK system code is to call the SecurityManager method to check the current policy and access control check. No matter when an applet is running, you typically install a security manager (SecurityManager implementation); AppletViewer and most browsers (including browser including Netscape and Microsoft) have security managers.
The security manager cannot be automatically installed when you run an application. In order to run the downloaded applet, the same security policy is applied to an application in a local file system, and users run the application must use the new "-djava.security.manager command line" command (it sets Java) . Structure.manager's value) to call the Java virtual machine, as shown below:
Java -djava.security.manager someApp
Alternatively, the application itself must call the SetSecurityManager method in the java.lang.system class to install a security manager.
You can specify a special security manager with a command line. The method is to add a equal sign after "-djava.security.manager, plus the class name that will be used as the security manager. As follows:
Java -djava.security.manager = com.abc.mysecmgr someApp
If there is no security manager being specified, a built-in default security manager will be used (unless the application has a different security manager). The following lines of order are equivalent, they will have the default security manager:
Java -djava.security.manager someApp
Java -djava.security.manager = "" SomeApp
Java -djava.security.manager = default someApp
JDK1.2 includes an attribute called java.class.path. Those classes that are stored in the local file system but not as a basic class should be under this path. In this path, you are loaded with a secure class loader and comply with the currently implemented security policies.
There is also a "-djava.security.policy" command line from variable, which determines what policy files should be used. This command line variable is detailed in the "Default System and User Policy File" section. In general, if you do not include "-djava.security.policy in a command line, the policy file specified in the security properties file will be used.
When calling an execution of an application file, you can use a "-djava.security.policy command line" to specify an additional or different policy files. For example: if you type the following command line (here the PURL is a URL of a specified policy file location), the policy file specified by the URL will also be loaded in addition to all the policy files specified in the security properties.
Java -djava.security.manager -djava.security.policy = PURL SomeApp
If you don't do this, but use the following command, that is, the double equity is used instead of the above order, only the specified policy file is used, and other policy files will be ignored:
Java -djava.security.manager -djava.security.policy = = pURL SomeApp6.2 SecurityManager and AccessController
The new access control mechanism is compatible with all backwards. For example, all CHECK methods in SecurityManager are still supported (although most of their implementations have been changed to call the Checkpermission method in the new SecurityManager, their default implementation calls AccessController's Checkpermission method). Note: Some internal security checks may reside in the SecurityManager class unless it can be parametric.
So far, we have not modified any JDK code system to call AccessController instead of calling SecurityManager (and check the existence of the loader), which is because existing third-party applications may create a securityManager subclass and make the Check method . In fact, we have added a new method securityManager.checkpermission, which is default directly to AccessController.checkpermission.
To understand the relationship between SecurityManager and AccessController, you should pay attention to: SecurityManager represents a core concept of access control, and AccessController is a specific access control algorithm (some special nature such as DOPRIVILEGED). By maintaining the continuous update of SecurityManager, we maintain backward compatibility (for example, compatible with applications that are based on early JDK versions) and flexibility (for example, some programmers wish to customize security mode) To achieve mandatory access control and multi-layer security control). We built a built-in algorithm by providing AccessController. We believe that the algorithm is the most restrained and can freelance programmers have to write a lot of security code in many cases.
We encourage the use of AccessController in the application code, the Usercraft Security Manager (by establishing a subclass) should be the last means, and should be careful when doing. In addition, a user-friendly security manager (if you want to check the time-time manager before calling the standard security check) should also be able to utilize the algorithm provided by AccessController at any suitable time.
6.3 Auxiliary Tools
This section will simply introduce three tools that help deploy new security performance. These tools may be packaged together in the future.
Text related to these tools can be found in the subdirectory of the JDK publishing directory:
/ DOC / TOOLDOCS / Solaris and / Doc / ToolDocs / Win32
The path separator here is actually "/" in the Windows system.
For example, if JDK is installed in a directory named "/jdk1.2" in the Solaris system, then the keytool text for Solaris users and Windows users is in the following directory:
/jdk1.2/docs/tooldocs/solaris/keytool.html
/jdk1.2/docs/tooldocs/win32/keytool.html
If JDK is installed in a directory called "C: /JDK1.2" in the Windows system, then the keytool text for Solaris users and Windows users is in the following directory:
C: /jdk1.2/docs/tooldocs/solaris/keytool.html
C: /jdk1.2/docs/tooldocs/win32/keytool.html6.3.1 Key and certificate management tool
KeyTool is a key and certificate management tool. It enables users to manage their own public / private key pairs and related certificates from my authentication (self-certification is self-authentication to other users / services), or use digital signatures to manage data integrity and certification. service. The authentication information includes both the sequence (chain) of the X.509 certificate and a related private key (it can be referenced by the so-called "alias"). This tool can also manage certificates (which is "trust" by the user), which is stored as authentication information in the same database and can be referenced by "alias".
KeyTool stores a key and certificate in a so-called KeyStore. The default KeyStore is implemented in file form. It protects private keys with passwords.
The chain of the X.509 certificate is provided by an organization called the certification center (or CA). Identity (including CA) uses their private key to authenticate their association with the object (such as using SSL protection), associated with the code document they signed or the X.509 certificate issued with them (including CA) Association, etc. As a "unlock" tool, the certificate generated using the -genkey command may be used to return a certificate chain to a certification center.
The private key in this database is always stored in encrypted form, which makes these private keys are difficult to obtain. Access or modify the database requires a password. These private keys are encrypted using "password", which may have several words. If the password is lost, those authentication keys will not be recovered.
In fact, each private key in KeyStore can be protected using its own password, which may be the same as the password that protects KeyStore, or may be different.
This tool is to use in the command line (under the current situation). In the command line, you can type "keytool" as a command. KeyTool is an executable Java class command file, which is built with JDK.
The options for this command can be provided in any order. Incorrect options or type "KeyTool -help" to output the tool usage summary on the output device (such as a housing window). As follows:
% KeyTool -help
KeyTool usage:
-certreq [-V] [-alias
] [-sigalg
]
[-file
] [-Keypass
]
[-keystore
] [-storepass
] [-storeType
StoreType] -delete [-v] -alias
[-keystore
] [-storepass
] [-storeType
StoreType] -export [-v] [RFC] [-alias
] [-file
] [-keyStore
] [-storepass
] [-storeType
StoreType] -Genkey [-V] [-alias
] [-KEYALG
] [-keysize
] [-sigalg
] [-dname
] [-Validity
] [-Keypass
] [-keyStore
] [-storepass
] [-storeType
StoreType] -help -identitydb [-v] [-file
] [-keyStore
] [-storepass
] [-storeType
StoreType] -Import [-v] [-noprompt] [-alias
] [-file
] [-Keypass
] [-keyStore
] [-storepass
] [-storeType
StoreType] -KeyClone [-V] [-alias
] -Dest
[-keypass
] [-new
] [-keyStore
] [-storepass
] [-storeType
StoreType] -KeyPasswd [-v] [-alias
] [-Keypass
] [-new
] [-keyStore
] [-storepass
] [-storeType
StoreType] -List [-v | -rfc] [-alias
] [-keyStore
] [-storepass
] [-storeType
StoreTcert [-v] [-file
] -selfcert [-V] [-alias
] [-sigalg
] [-dname
] [-Validity
] [-Keypass
] [-keyStore
] [-storepass
] [-storeType
StoreType] -storepasswd [-v] [-new
] [-keyStore
] [-storepass
] [-storeType
StoreType]
6.3.2 Strategy Tools
The policy tool is a graphical user interface (as shown by screen graphics), which helps users (such as system administrators) specify, generate, edit, output, or enter a security policy. This tool is called from the command line as PolicyTool. This is another command file, which is built with JDK to call the appropriate (non-public) implementation class.
For more information, see the text and the latest screen graphics for the policy tool usage. The above text is stored in the policytool.html file, in the following path:
/ DOCS / TOOLDOCS / Solaris / or / DOCS / TOODOCS / WIN32 /
The file separator here is actually a backslash in the Windows system. 6.3.3 JAR Signature and Check Tools
The Jarsigner tool can be used to sign the Java Document (JAR file) and verify this signature. Similar to policy tools, this tool depends on KeyStore managed by KeyTool. Its usage can be quickly summed:
% jarsigner
USAGE: JARSIGNER [OPTION] JAR-FILE Alias
Jarsigner -verify [options] JAR-FILE
[-keystore
] KeyStore File Location
[-storepass
] Password for KeyStore Integrity
[-keypass
] Password for Private Key (if Different)
[-sigfile
] Name of .sf / .dsa file
[-signedjar
] Name of signed JAR file [-verify] verify a signed JAR file [-verbose] verbose output when signing / verifying [-certs] display certificates when verbose and verifying [-internalsf] include .SF file inside signature block [-sectionsonly] Don't compute hash of entire manifest
This tool is also a command file that is built with JDK. We hope this tool and JAR tool command can be merged in the future to form a single primitive language for creating JARS (signword or not signed). ........ | Next | ......... Welcome to contact us: Webmaster@prc.sun.com Copyright 1997-1998 Sun (China) Company, Beijing South Gifts 16th Floor, Jianwei Building, No. 66 Road, ALL Rights Reserved.lege
