JSPWiki: Bug Code Signing Is Unnecessary

More...

Title	Code signing is unnecessary
Date	25-Feb-2006 01:04:17 EET
Version	2.3
Submitter	89.55.177.112
Bug criticality	LightBug
Browser version
Bug status	NotReallyBug
PageProvider used
Servlet Container	Tomcat 5.5
Operating System	Win32, Linux
URL
Java version	5.0

JSPWiki uses jspwiki.policy entries like ({) grant signedBy "jspwiki" principal com.ecyrd.jspwiki.auth.authorize.Role "Asserted" (})

The signedBy is unnecessary, it suffices to grant to principals.

I deleted all signedBy "jspwiki", the security code still works. I tested Sun JDK 5.0 with XP and Linux.

The signing makes development unnecessarily difficult.

This is not a bug, because code-signing is needed to support certain deployment scenarios. This is perhaps a slight impediment to development, but I think we've done the best we can to make code-signing easy. The Ant scripts will auto-generate a key for you (with sensible defaults) whenever you build JSPWiki from scratch. So I think the comment "unnecessarily difficult" is a little harsh.

As for why we need to do code-signing, it's NOT necessary in the default case where you drop a WAR into a servlet container and use JSPWiki as a single, stand-alone wiki. But for multi-wiki deployments in the same container, or for those cases where the implementer wishes to specify an external security policy file, then we need our code to be signed. Specifically, it has to do with the way Permission classes are loaded and evaluated by the Java access control classes. JSPWiki makes extensive use of custom Permission types (PagePermission, WikiPermission and AllPermission).

Here's an excerpt from the definitive book, Inside Java 2 Platform Security, 2nd Edition, by Li Gong, that explains why this is so:

Many Permission classes referenced by the policy configuration exist locally. That is, those classes can be discovered by the Policy provider's defining class loader or another loader it delegates to, such as the bootstrap class loader. Objects for such permissions can be instantiated during Policy initialization. For example, it is always possible to instantiate a java.io.FilePermission, as the FilePermission class is bound on the bootstrap class path.

However, [it is possible that] when the Policy object is constructed, the code that implements a particular Permission class has yet to be loaded or is not available for loading. For example, a referenced Permission class might be in a JAR file that will eventually be downloaded. In this case, the Permission has yet to be defined within the Java runtime environment. For such a class, an UnresolvedPermission object is instantiated instead, as a placeholder that contains information about the permission... Unresolved permissions of a particular type must be resolved before an access control decision can be made about a permission of the actual type... To resolve an UnresolvedPermission, the policy decision point must locate and instantiate the appropriate permission class type...

A few methods... in the UnresolvedPermission class are

public UnresolvedPermission(String type, String name, 
String actions, java.security.cert.Certificate certs[]);

public boolean implies(Permission p);

public boolean equals(Object obj);

Note that the constructor takes an array of certificates, which can be used to verify the signatures on the permission class. Remember that UnresolvedPermissions enable the deferred loading of permission classes so that a given permission class need not be defined until necessary. The very nature of such permission classes suggests that a more rigorous mechanism is required to ensure their authenticity. By signing a given permission class and specifying the signing requirement in the security policy, we have a foundation that can be used to assure us that the permission class respects the intentions of the root class java.security.Permission and that the implementation is not malicious. Of course, this assurance depends on the trust conveyed by the signature keys used to sign the class. However, without this mechanism, it would be up to the application to make this trust decision, which would be difficult, if not impossible, for the application to do. [emphasis mine]

Thus -- the logic works like this...

If the classes containing our custom permissions are all loaded before the Policy is set, then we don't need to sign them. For stand-alone, out-of-the-box JSPWiki implementations that do not also specify an external policy file via the java.security.policy system property at startup, all classes will be loaded before JSPWiki sets its custom policy.

However, it is not safe to assume that all environments work this way. In some (mine, for instance), the admin will wish to set the policy file manually. In this case, the JSPWiki Permission classes will not be available to the Java Policy object at JVM startup. Thus, they are instantiated initially as UnresolvedPermission instances. Therefore, we must have our JAR signed in order for them to become "resolved."

P.S. Li Gong's book is outstanding, by the way, and I recommend it to anyone who wishes to explore the innards of Java security. Took me several read-throughs to really grok it, but it was well worth the effort.

-- Andrew Jaquith, 29 March 2006

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 17-Jul-2006 11:30 by 211.53.198.25.

G’day (anonymous guest) My Prefs

This site

JSPWiki

Development

Internet Search

Referenced by
...nobody

JSPWiki v2.8.4-svn-9