Java Security Notes

【From Java Security 2nd Edition】

Architecture

0. code base setting
The ending of the code base URL is very important. There are four cases:
http://mylab/sdo/sdoapp.jar Only the classes in the jar file belong to the code base.
http://mylab/sdo/ Only class files in the given directory belong to the code base. Jar files in the given directory do not belong to the code base.
http://mylab/sdo/* Both jar files and class files in the given directory belong to the code base. However, jar and class files in subdirectories of the URL do not belong to the code base.
http://mylab/sdo/− All jar and class files in the given directory and its subdirectories belong to the code base.
the disk space could like this: file:/c:/files/jdk

1. Policy files (codebase + signedBy)
There is a global policy file named $JREHOME/lib/security/java.policy that is used by all instances of a virtual machine on a host.In addition, there is a user−specific policy file called .java.policy that may exist in each user's home directory ($HOME on UNIX systems, C:\WINDOWS on single−user Windows systems, and so on).

keystore "${user.name}${/}.keystore"

grant signedBy "sdo", codeBase "http://mylab/"{
permission java.sercurity.AllPermission;
};

Provider&Security
Digest: data hash; MD5, SHA-1
Signature: Digest + secure key encryption

The provider configured in the file java.security was managed by Security class. and all the engine class use Security lass to provide Object. for example: JSSEProvider, it will register all the info(engine and algorithm: such as, 'KeyManagerFactory.X509') about the following implementation 3rd class.

Service Provider Interface: define the expected behavior in the provider.
Especially, the sslsocketfactory and the sslserversocketfacotory is configurated from the java.security.

Implementation

It depends on:

• The security manager, which provides the mechanism that the Java API uses to see if security−related operations are allowed.
• The access controller, which provides the basis of the default implementation of the security manager.
• The class loader, which encapsulates information about security policies and classes.

1.
The access controller can do everything the security manager can do.The reason there is both an access controller (java.security) and a security manager (java.lang) is mainly historical. Starting with Java 2, the security manager defers these decisions to the access controller . Since the security policy enforced by the access controller can be specified by using policy files, this allows a much more flexible mechanism for determining policies.

But the large body of pre−Java 2 programs dictates that the primary interface to system security −− that is, the security manager −− cannot change; otherwise, existing code that implements or depends on the security manager would become obsolete. Hence, the introduction of the access controller did not replace the security manager −− it supplemented the security manager.

The security manager is used only if it is explicitly installed. When you run a Java application, specifying the −Djava.security.manager option installs a security manager. The security manager is installed programatically by the appletviewer and the Java Plug−in.Hence, this point cannot be overemphasized: Java applications (at least by default) have no security manager while Java applets (again, by default) have a very strict security manager.

import java.applet.*;
public class MaliciousApplet extends Applet {
public void init( ) {
try {
Runtime.getRuntime( ).exec("rmdir foo");
} catch (Exception e) {
System.out.println(e);
}
} ...

If you compile this code, place it on your web server, and load it as an applet, you will get an error reflecting a security violation. However, if you compile this code, place it in a directory, and then run it as an application (without using the −Djava.security.manager option), you'll end up deleting the directory named foo in your current directory. As a user, then, it's crucial that you understand which security manager is in place when you run a Java program so that you understand just what types of operations you are protected against.

Interaction with API
1. The programmer makes a request of the Java API to perform an operation.
2. The Java API asks the security manager if such an operation is allowable.
3. If the security manager checking permission, which will check all the revolved class, is false, it throws an exception back to the Java API, which in turn throws it back to the user.
4. Otherwise, the Java API completes the operation and returns normally.

2.
The access controller is built upon the four concepts :
Code sources (LJava.security.CodeSource)
An encapsulation of the location from which certain Java classes were obtained.
Permissions (Ljava.lang.Permission, BasicPermission, PermissionCollection[same type permission set], Permissions[not limited type permission set])
An encapsulation of a request to perform a particular operation.
Policies (java.security.Policy)
An encapsulation of all the specific permissions that should be granted to specific code sources. Only a single instance of the policy class can be installed in the virtual machine at any time. However, the actual instance of the policy class can be replaced.
Protection domains ((java.security.ProtectionDomain)
An encapsulation of a particular code source and the permissions granted to that code source.

Whether the access controller allows or rejects a given permission depends upon the set of protection domains that are on the stack when the access controller is called.

Often, however, you want a class to be temporarily given the ability to perform an action on behalf of a class that might not normally have that ability. In this case, we might want to establish a policy where the classes

Consider this in terms of writing a file: an applet might not be able to write a file, but it can call a method of the SDK to play audio data which means the SDK class must write to the audio device file.

【From the JavaDoc】
Suppose the current thread traversed m callers, in the order of caller 1 to caller 2 to caller m. Then caller m invoked the checkPermission method. The checkPermission method determines whether access is granted or denied based on the following algorithm:

i = m;
while (i > 0) {
if (caller i's domain does not have the permission) throw AccessControlException

else if (caller i is marked as privileged) {
if (a context was specified in the call to doPrivileged)
context.checkPermission(permission);return;} i = i -1;

So protection domain can grant privileges to code that has called it, but it cannot grant privileges to code that it calls.

But the permissions that a class loader should use to determine whether a new class can be loaded should be determined by the protection domains of the stack that created the class loader rather than any subsequent users of that class loader.

What can we do?
Use : public final class AccessControlContext
Build a context based on a set of protection domains.
Instances of this class are returned by the getContext( ) method of the AccessController class.
That method takes a snapshot of the protection domains that are on the stack when it is called and stores those domains into the returned access context object.

You can then use that context object in a later call to the access controller; the access controller will use that set of protection domains in its operation rather than the set of domains that are on the stack. You can imagine the usage of this class in application code is very limited, ONLY in class loader.

Support

Engine Class:
KeyStore: store the secure key and the certifications and usually in the primary directory of the user .keystore.