[jboss-dev] Refactoring packaging/packages to reduce "signed jar groups"

[Brian Stansberry]

The exception Mike showed is specified in the javadoc of 
java.lang.ClassLoader protected final Class<?> defineClass(String name, 
byte[] b, int off, int len)

* @throws  SecurityException
*          If an attempt is made to add this class to a package that
*          contains classes that were signed by a different set of
*          certificates than this class (which is unsigned), or if
*          <tt>name</tt> begins with "<tt>java.</tt>".


On 02/25/2010 08:58 AM, Mike Clark wrote:
> Hey Dimitris,
>
>   From what I read, sealing implies that packages must be loaded from a
> single jar, signed or not.  We do load the same package from multiple
> jars.  In addition, We should see a "java.lang.SecurityException:
> sealing violation at java.net.URLClassLoader.defineClass()" [1] in the
> case of a sealing violation.   So, I think sealing is a red-herring with
> respect to this discussion.
>
> Cheers,
> Mike C.
>
> [1] http://java.sun.com/developer/JDCTechTips/2001/tt0130.html#files
>
> On 02/25/2010 08:49 AM, Dimitris Andreadis wrote:
>> Could it be that signing implies package sealing? Can you tried setting explicitly sealing
>> to off?
>>
>> Mike Clark wrote:
>>
>>> Hey Adrian,
>>>
>>>    From reading the links you provided, it doesn't seem to be a sealed
>>> package thing.  Indeed, we do not seal the jars.  The error is, for example:
>>>
>>> 2010-02-25 08:36:00,520 INFO  [org.jboss.web.WebService] (main) Using
>>> RMI server codebase: http://127.0.0.1:8083/
>>> 2010-02-25 08:36:00,621 WARN
>>> [org.jboss.detailed.classloader.ClassLoaderManager] (main) Unexpected
>>> error during load of:org.jboss.naming.NamingService
>>> java.lang.SecurityException: class "org.jboss.naming.NamingService"'s
>>> signer information does not match signer information of other classes in
>>> the same package
>>>        at java.lang.ClassLoader.checkCerts(ClassLoader.java:776)
>>>        at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488)
>>>        at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>>>        at
>>> org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
>>>        at
>>> org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
>>>        at
>>> org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
>>>        at java.security.AccessController.doPrivileged(Native Method)
>>>        at
>>> org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
>>>        at
>>> org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
>>>        at
>>> org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
>>>        at
>>> org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
>>>        at
>>> org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
>>>        at
>>> org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:267)
>>>        at
>>> org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:166)
>>>        at
>>> org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
>>>        at
>>> org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
>>>        at
>>> org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
>>>        at
>>> org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
>>>        at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>>>
>>> (This is from line 2 of the server.log when you replace jboss.jar in EAP
>>> 5 with an unsigned version.)
>>>
>>> Cheers,
>>> Mike C.
>>>
>>> On 02/25/2010 07:27 AM, Adrian Brock wrote:
>>>
>>>> On Wed, 2010-02-24 at 16:50 -0600, Mike Clark wrote:
>>>>
>>>>
>>>>> Hey folks,
>>>>>
>>>>> The general purpose of this note is to explore refactoring some of our
>>>>> jars to reduce some problems that have come about due to our signing
>>>>> of jars.
>>>>>
>>>>>
>>>> <snip/>
>>>>
>>>>
>>>>
>>>>> The problem with such a substitution is the fact that a classloader
>>>>> will not load classes from a packages that appear in differently
>>>>> signed jars.  So, for example, even though class org.jboss.A may only
>>>>> occur in an unsigned A.jar, loading it will cause a security exception
>>>>> if class org.jboss.B was loaded from a signed B.jar.
>>>>>
>>>>>
>>>> I don't understand this, what error message are you seeing?
>>>>
>>>> Signing jars (which is about verifying the bytes have not been
>>>> tampered with - and potentially granting additional security
>>>> permissions)
>>>> http://java.sun.com/docs/books/tutorial/deployment/jar/intro.html
>>>> has nothing to do with what you describe, which sounds like package
>>>> sealing?
>>>> http://java.sun.com/docs/books/tutorial/deployment/jar/sealman.html
>>>>
>>>> See definePackage() here:
>>>> http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloader/src/main/java/org/jboss/classloader/spi/base/BaseClassLoader.java
>>>> for how we currently implement package sealing.
>>>>
>>>> AFAIK, Package::isSealed(URL) just does an equals check on the URL,
>>>> it doesn't look at the CodeSource's certificates.
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat