1.Two aspects
a. Secure the Java platform itself, such as bytecode verification, class loading protection
b. Provide services and tools for java applications, such as cryptography, authentication.
2.Secure the Java platform
2.1 Old Mechanism(JAVA 1): Sandbox
Forget about it
2.2.New Mechanism(Since JAVA 2)
Think about it in a general way of security: "Can a principal access a resource?"
The concepts in java security apply to this generic approach:
a.Who is the principle? CodeBase — a set of java codes who try to visit the resources, "file:/home/sys/" for example
b.What are the resources? Classes, File Systems, and so on…
c.How are the resources organized? Permission — a set of resources
d.How to decide whether codes from a code base can have a specified permission? Policy.
For example
grant codeBase "file:/home/sysadmin/" {
permission java.io.FilePermission "/tmp/abc", "read";
};
e.Any Exception to this mechanism? Yes, privileged blocks can access resources even if they are not permitted
3.Policy Implementation
3.1 Default implementation
a. Global policy files: $java.home/lib/security/java.security, and so on
b. Runtime policy files, adding to or replacing the global configuration: java -Djava.security.manager -Djava.security.policy=someURL SomeApp
3.2 Other implementation
You can set it via ‘policy.provider=PolicyClassName’ in java.security
Appendix 1.Resources
a.Architecture: http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-spec.doc.html
b.Policy Implementation: http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html