|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 {{UnresolvedPermission}}s 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 

----

As of 2.5.68, code signing is no longer necessary, unless you wish to use a global policy.

-- JanneJalkanen