Java. Policy file format and usage

I. Java Security Policy Concept

Java applicationsProgramThe environment security policies are described in detail for differentCodeThe permission of different resources is expressed by a policy object. To enable the applet (or an application running under securitymanager) to execute protected behaviors, such as reading and writing files, the applet (or Java application) must obtain the permission for that operation, the security policy file is used to implement these licenses.

The policy object may have multiple entities, although only one of them can work at any time. The currently Installed Policy object can be obtained by calling the getpolicy method in the program or by calling the setpolicy method. The policy object evaluates the entire policy, returns an appropriate permissions object, and details which code can access which resources.

Policy files can be stored in unformatted ASCII files, policy-class binary files, or databases. This article only discusses the format of non-formatted ASCII files.

Ii. Policy File Format

To better understand the following content, we recommend that you refer to the contents of the jdk1.2jrelibsecurityjava. Policy file and jdk1.2jrelibsecurityjava. Security file when you read this document.

Syntax format and description of the policy file

A policy file is essentially a record list, which may contain one "keystore" record and zero or multiple "Grant" records. The format is as follows:

Keystore "some_keystore_url", "keystore_type ";

Grant [signedby "signer_names"] [, codebase "url"] {

Permission permission_class_name ["target_name"]

[, "Action"] [, signedby "signer_names"];

Permission...

};

(1) "keystore" Record

A keystore is a private key database and a digital signature, such as an X.509 Certificate. The policy file may have only one keystore record (or this record may not exist), which can appear anywhere except the grant record in the file. The keystores specified in the policy configuration file is used to find the Public Key (public keys) of the signer specified in the grant record. If any grant record specifies the signer_names, the keystore record must appear in the policy configuration file.

"Some_keystore_url" refers to the URL location of the keystore, and "keystore_type" refers to the keystore type. The second option is optional. If not specified, this type is determined by the "keystore. Type" attribute in the Security Attribute file (Java. Security. The keystore type defines the storage and data format of keystore information, which is used to protect the integrity of private keys and keystore in the keystore.Algorithm. Sun Microsystems supports "jks" by default ".

(2) "Grant" Record

Each grant record in the policy file contains a codesource (a specified code) and its permission (license ).

Each grant record in the Policy File follows the following format and starts with the reserved word "Grant", indicating the start of a new record. "permission" is another reserved word, indicates the start of a new license in the record. Each grant record grants a Specified Code (codebase) and a set of licenses ).

Permission_class_name must be a qualified and existing class name, such as Java. Io. filepermission, and cannot be abbreviated (for example, filepermission ).

Target_name is used to specify the location of the target class, and action is used to specify the permissions of the target class.

Target_name can directly specify the class name (which can be an absolute or relative path), directory name, or the following wildcard:

All files under directory /*

* All files in the current directory

All files in the directory, including subdirectories

-All files in the current directory, including subdirectories

<All files> all files in the file system

For Java. Io. filepermission, the action can be: read, write, delete, and execute.

For java.net. socketpermission, the action can be: Listen, accept, connect, read, and write.

(3) The property expansion property extension in the policy file is similar to the variable extension used in the shell. Its format is "$ {some. Property }"

An example is as follows:

Permission java. Io. filepermission

"$ {User. Home}", "read ";

"$ {User. the value of home} "is" D: Project ". Therefore, the following statement is the same as the preceding statement: Permission Java. io. filepermission "D: Project", "read ";

Iii. Example

When initializing the policy, first load the system policy and then add the user policy. If neither of them exists, use the Default policy, that is, the original Sandbox Model.

The default location of the system policy file is:

{Java. Home}/lib/security/Java. Policy (Solaris)

{Java. Home} libsecurityjava. Policy (Windows)

The default location of the user policy file is:

{User. Home}/. java. Policy (Solaris)

{User. Home}. java. Policy (Windows)

In fact, in actual use, we may not be as complex as described above, especially when no digital signature is used. At this time, we can fully learn from the ready-made jdk1.2jrelibsecurityjava provided by JDK 1.2. policy file, which is modified according to our needs. This article describes the usage of the security policy file in detail when no digital signature is used.

The following is a complete. java. Policy file used in windows. In the file, the usage of each "permission" record is described in the form of annotations respectively.

 

// For lanservertalk. Java and lanclienttalk. Java

Grant {

// Read the system and user directory

Permission java. util. propertypermission "user. dir", "read ";

Permission java. util. propertypermission "user. Home", "read ";

Permission java. util. propertypermission "Java. Home", "read ";

Permission java. util. propertypermission "Java. Class. Path", "read ";

Permission java. util. propertypermission "user. Name", "read ";

// Operation permissions on threads and thread groups

Permission java. Lang. runtimepermission "modifythread ";

Permission java. Lang. runtimepermission "modifythreadgroup ";

// Perform operations on various permissions on the socket Port

Permission java.net. socketpermission "-", "listen ";

Permission java.net. socketpermission "-", "accept ";

Permission java.net. socketpermission "-", "Connect ";

Permission java.net. socketpermission "-", "read ";

Permission java.net. socketpermission "-", "write ";

// ACL for reading and writing files

Permission java. Io. filepermission "-", "read ";

Permission java. Io. filepermission "-", "write ";

// Permission to exit the system, such as system. Exit (0)

Permission java. Lang. runtimepermission "exitvm ";

};

Iv. Use of the. java. Policy File

For Windows 95/98/NT, there are two methods to use the. java. Policy file.

1. Use the default directory

We can simply edit it. java. copy the policy file to the Home Directory of Windows 95/98/NT. In this case, all the applets (or Java applications) may have the same permissions, which is easy to use, but not flexible (for example, for Java. io. filepermission, The target_name of the target class must use an absolute path). If it is not used in the enterprise intranet, there may be some security risks.

2. Specify

In the command line, if we want to pass a policy file to appletviewer, you can also use the "-J-Djava.security.policy" parameter to specify the location of the policy:

Appletviewer-J-Djava.security.policy = purl myapplet

Purl is the location of the policy file. Handler (load and run lanservertalk. Java in the file ):

Appletviewer-J-Djava.security.policy =. java. Policy lanservertalk.html

This method is flexible, especially when a software package is released on the enterprise intranet, the software is installed, set up, and migrated without having to modify the content of the policy file, scope control of security licenses is fine-grained.

Grant {
Permission java. Security. allpermission;
};