This section describes how to specify a level of security checks to be performed when an applet is executed.
The Java VM of the J2SE uses a policy file for configuring security level. A policy file describes permissions which allows applets to do the operations subjected to security checks. A policy file enables more flexible security control than that of the Java platform 1.1.
When JBK Plugin works with the J2SE, it uses the policy file for the security control of the applet. For the policy files used by JBK Plugin, look at the notes below. Also check the JDK document for the detail of the security control with the policy file.
Policy Files Used by JBK Plugin
JBK Plugin uses the following two policy files:
JBK Plugin policy file
The following line in jbkplugin.properties describes the directory where the JBK Plugin policy file is located:
jbk.plugin.policy.url=<policy-file-url> |
In <policy-file-url>, the user describes the absolute path of the policy file as the URL form. The default setting is:
file:${jbk.home}/classes/jbkplugin.policy
${jbk.home} means the directory where JBK is installed.
When the installation folder includes spaces, do not use ${jbk.home} in the jbk.plugin.policy.url. Reading of the policy file will fail.
The default policy file of the JavaSE
The JavaSE has its policy file in the following directory:
JDK : <JDK-directory>\jre\lib\security\java.policy
JRE : <JRE-directory>\lib\security\java.policy
common : (${user.home})\.policy
Permissions described in both policy files are valid. If permissions for the same applet are described in both files, both descriptions are valid.
You can describe permissions in either of them. If you use the JBK Plugin policy file, you do not need to re-describe the permissions when you change the Java VM used in JBK Plugin, or when you re-install the Java VM.
Example
Sample Description of the Policy File
The following is a sample description of the policy file. This allows an applet to do all operation subjected to security checks.
grant codeBase "(the codebase of the applet)" {
//AllPermission allows all permissions to the applet.
permission java.security.AllPermission;
}; |
Note that AllPermission in this sample description enables all permissions for the applet.
In actual operation, specify only the necessary permissions, not AllPermission.
Point
If you do not want to use the JBK Plugin policy file, delete the line of "jbk.plugin.policy.url" in jbkplugin.properties, or insert '#' at the beginning of the line.
Required Permission for Each Operation
The table below lists the required permissions for the operations subjected to security checks. See the JDK documentation for the detail of these permissions and how to specify them in the policy file.
Operation to be checked | Required permission |
|---|---|
Reading a local file | (using the file descriptor) |
(using the file name) java.io.FilePermission "<file>","read"; | |
Writing a local file | (using the file descriptor) java.lang.RuntimePermission "writeFileDescriptor"; |
(using the file name) java.io.FilePermission "<file>","write"; | |
Deleting a local file | java.io.FilePermission "<file>","delete"; |
Asking for a network connection (connect) | (using -1 as the port number) java.net.SocketPermission "<host>","resolve"; |
(otherwise) java.net.SocketPermission "<host>:<port>","connect"; | |
Waiting in a network port (listen) | (using 0 as the port number) java.net.SocketPermission "localhost:1024-","listen"; |
(otherwise) java.net.SocketPermission "localhost:<port>","listen"; | |
Accepting a request for a network connection (accept) | java.net.SocketPermission "<host>:<port>","accept"; |
Using the multicast mode | java.net.SocketPermission(maddr.getHostAddress(),"accept,connect"); |
Setting the factory of a network-related class | java.lang.RuntimePermission "setFactory"; |
Operating a thread of a different thread group | (operating a thread) java.lang.RuntimePermission "modifyThread"; |
(operating a thread group) java.lang.RuntimePermission "modifyThreadGroup"; | |
Starting a local application | (specifying the absolute path for the command) java.io.FilePermission "<cmd>","execute"; |
(specifying the relative path for the command) java.io.FilePermission "-","execute"; | |
Loading a local library (DLL) | java.lang.RuntimePermission "loadLibrary.<lib>"; |
Accessing the system property | (using System.getProperties()) java.util.PropertyPermission "*","read,write"; |
(using System.getProperty(String key)) java.util.PropertyPermission "<key>","read,write"; | |
Creating a window | java.awt.AWTPermission "showWindowWithoutWarningBanner"; |
Loading a class from an applet | java.lang.RuntimePermission "getClassLoader"; |
Accessing a print job | java.lang.RuntimePermission "queuePrintJob"; |
Accessing the clipboard | java.awt.AWTPermission "accessClipboard"; |
Accessing the AWT event queue | java.awt.AWTPermission "accessEventQueue"; |
Operating the class loader | java.lang.RuntimePermission "getClassLoader"; |
Terminating the browser | (With JBK Plugin, an applet cannot terminate the browser.) |
Note
Compared with JBK Plugin V3, JBK Plugin V4 strengthens the security check of the applet. For this reason, the applet running JBK Plugin V3 may encounter the following case:
When the applet connects with the Web server via a proxy, and the host name of the Web server is not registered in DNS, it may takes several minutes to establish the connection.
If it makes trouble for you, you can specify 'jbk.plugin.security.strict=false' in jbkplugin.properties. Then, JBK Plugin uses the same security check as V3.
In the case the applet encounters any security error, however, you should not use 'jbk.plugin.security.strict=false'. You should add proper permissions in the policy file, instead.
