You are not logged in Log in Join
You are here: Home » Members » jim » ZopeSecurity » JavaSecurityModel » wikipage_view

Log in
Name

Password

 
 

JavaSecurityModel

A summary of the Java Security Model

I've taken a cursory look at the Java 1.2 Security, model for comparison with Zope's present and future models.

If I've gotten anything wrong or missed something important, I hope someone will correct me.

Java's security model is based on classes, Permissions, Policies, and programmer-performed run-time permission checks.

Permissions
Permissions, are abstract objects. They are defined by a permission class and 0 or more string parameters.

Examples:

  • java.lang.RuntimePermission("exitVM")
  • java.net.SocketPermission?("*.com","connect")
  • java.io.FilePermission?("myfile", "read,write")

Permissions can imply other permissions.

Policies
Policies, define which classes have which permissions. Policies no not express what permissions are needed to use a class.

Policies seem to be global settings. There doesn't seem to be any notion of server apps that provide different policies for different human users.

Policies are assigned to classes based either on class location or on the class provider (owner) as expressed through a cryptographic signature, where the signature is contained in a .jar file.

The last piece of the puzzle is defining what permissions are needed to perform actions. This is done through explicit checks in Java code. When a bit of code wants to perform some action that should be protected, the code makes an explicit call to check whether the calling classes have the necessary permission:

      SecurityManager security = System.getSecurityManager();
      if (security != null) {
          FilePermission perm = new FilePermission("path/file", "read");
          security.checkPermission(perm);
      }

This seems too hard. There must be an easier way, but I haven't found it. (I haven't tried that hard, someone please correct me if I'm wrong.)

Note that I said "classes" above. Normally, every class in the call stack must have the specified permission or a permission that implies the specified permission. Eek! There is a way to short-curcuit this so that the check only goes up to a specified boundary.