If you also read the book, you will observe I did not follow the book's chapter fully. Because I think some logics need to be discussed together such as permission and policy files.
Yes, policy files are the place storing various security permission we have discussed before. Normally, the files are in $JREHOME/lib/security/. You could configurate any type of policy files for your Java Virtual Machine. However, the default one is named with java.policy that is used by all Java instance.
In addition, author said there is a user-specific policy file called .java.policy. But I can not find it in my JDK directory. Maybe my J2SE 1.4.2 has been changed. But I could list my java policy file here.
// Standard extensions get all permissions by default
grant codeBase "file:${java.home}/lib/ext/*" {
permission java.security.AllPermission;
};
// default permissions granted to all domains
grant {
// Allows any thread to stop itself using the java.lang.Thread.stop()
// method that takes no argument.
// Note that this permission is granted by default only to remain
// backwards compatible.
// It is strongly recommended that you either remove this permission
// from this policy file or further restrict it to code sources
// that you specify, because Thread.stop() is potentially unsafe.
// See "http://java.sun.com/notes" for more information.
permission java.lang.RuntimePermission "stopThread";
// allows anyone to listen on un-privileged ports
permission java.net.SocketPermission "localhost:1024-", "listen";
// "standard" properies that can be read by anyone
permission java.util.PropertyPermission "java.version", "read";
permission java.util.PropertyPermission "java.vendor", "read";
permission java.util.PropertyPermission "java.vendor.url", "read";
permission java.util.PropertyPermission "java.class.version", "read";
permission java.util.PropertyPermission "os.name", "read";
permission java.util.PropertyPermission "os.version", "read";
permission java.util.PropertyPermission "os.arch", "read";
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
permission java.util.PropertyPermission "java.specification.version", "read";
permission java.util.PropertyPermission "java.specification.vendor", "read";
permission java.util.PropertyPermission "java.specification.name", "read";
permission java.util.PropertyPermission "java.vm.specification.version", "read";
permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
permission java.util.PropertyPermission "java.vm.specification.name", "read";
permission java.util.PropertyPermission "java.vm.version", "read";
permission java.util.PropertyPermission "java.vm.vendor", "read";
permission java.util.PropertyPermission "java.vm.name", "read";
};
Now, all the Java Sandbox work according to this policy file. I take note of one change that my JRE's java policy file has not keystore configuration. Is it anything wrong on my install or configuration? I will investigate this one later.
If we try to manage Java Virtual Machine by policy file, we need to configurate it via permission rules. Yet this is not enough to guarantee security configuration.There are still another two sects--keystore and code source. Keystores is used to sign Java code and only after user get pulibc key, he can run the signed code. As for code sources, it's a combination of codebases and signers. That means that you must tell others which code is signed by what type of keystores.
Keystores, code sources and policy file are the foundation of Java security sandbox configuration. And how do they work? Some tools. If you are an old Sun user, you even can guess the tool's name--policytool.
I hate to write more boring operating steps here. I think you can find break-down in every Sun Java document.
Now we could put them together and examinate how it works. I will share my experience with you in next notes.