11:50 p.m.
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.
So, let me start with a description of the problem. Essentially, the
core issue is around the simple replacement of an EAP signed jar with an
unsigned jar. While we have a system in place to have QE get one-off
patches signed in a relatively responsive manner, we are still left with
cases such as a diagnostic jar created by support to track down
problems, or a customer that, understanding that it would not be
supported, wishes to make a change for their system (one of the
advantages of OSS, of course).
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. Now, the first step to
resolve this would be to replace both A.jar and B.jar with unsigned
versions. But, we then often run into a transitive entanglement. B.jar
may contain classes from package org.jboss, but also org.hibernate. So,
you have to have unsigned versions of C.jar and D.jar that contain the
hibernate packages. But, they have an org.apache package, and so on.
Using TattleTale with some custom reports, I generated "signed jar
groups" identifying clusters of jars that would need to all be replaced
as unsigned if any one is unsigned. For the largest group, I created a
graph of the dependencies shown in
http://community.jboss.org/wiki/SignedJarDependenciesExample
(getopt_jar_Group.png, named by the first jar listed in the group from
the report.)
The figure shows the jars with a line connecting them if they have one
or more packages in common (I also generate detailed plots with a
labelled line for each package in common if anyone wants to see them,
but for the "getopt" group, the detailed plot is quite large and hard to
read.) Clearly, lots of unrelated jars are wound up in this group.
But, we can chip away at this with a bit of analysis. I'll give three
examples.
First, consider the set of jar files just to the right of the center
grouped around jboss-ejb3-core.jar. This set of jars is tied into the
rest of the graph through the connection between
jboss-as-ejb3-deployer.jar and jboss.jar. The package that ties them is
org.jboss.as.javaee. In this case there appears to be only two classes
involved. In jboss.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleIdentifier and in
jboss-as-ejb3-deployer.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleInformer (which has an inner
class). So, in this case, we can break off a chunk of the signed jar
group by, for example, changing a package name:
org.jboss.as.javaee.ejb3.SimpleJavaEEModuleInformer
Next, from the graph, we can see that there is a group of jar files on
the far left that is tied in by a connection between the
jboss-system-jmx.jar and the jboss.jar. In this case, the package is
org.jboss.deployment. There are several classes in jboss.jar and a
handful in jboss-system-jmx.jar that are in this package. So, options
might include renaming the package for the classes in the
jboss-system-jmx.jar, moving them to jboss.jar, or separating the
org.jboss.deployment classes between them into a new jar:
jboss-deployment.jar.
Finally, staying on the far left of the graph we see that run.jar and
shutdown.jar are tied into some third party jars such as getopt.jar,
hsqldb.jar and jdom-1.0.jar. These are due to use of classes in the
default package. Further, the default package is included because the
contents of the getopt.jar are incorporated into run.jar and
shutdown.jar. So, this connection to third party jars can be broken out
by removing the GetOpt related classes from run.jar and shutdown.jar and
relying on the Class-Path: attribute in their manifests.
So, in the end, it would seem to be beneficial to refactor package
locations such that there is not such widespread entanglement. From the
signed jar perspective, it would be best if each package only appeared
in one jar. Of course, there are often engineering reasons to separate
classes in the same package into different jars. However, I think it's
not unreasonable that these should be relatively small in number and
they should be functionally coherent. At any rate, it would appear to
be something we could attack incrementally as indicated by the three
examples above.
Originally, when discussing this with other folks, we thought perhaps we
should just open jiras to address the problem. But, on considering
that, it seemed that perhaps a discussion on a larger game plan would be
a better approach, even if it just ended up with the original plan of
opening some jiras to "chip away" at the problem.
So, I apologize for a long, dense note. For those of you that made it
through, any thoughts, suggestions?
Cheers,
Mike C.
1:46 a.m.
Hey Mike,
On Wednesday 24 February 2010 17:50:22 Mike Clark wrote:
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.
So, let me start with a description of the problem. Essentially, the
core issue is around the simple replacement of an EAP signed jar with an
unsigned jar. While we have a system in place to have QE get one-off
patches signed in a relatively responsive manner, we are still left with
cases such as a diagnostic jar created by support to track down
problems, or a customer that, understanding that it would not be
supported, wishes to make a change for their system (one of the
advantages of OSS, of course).
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. Now, the first step to
resolve this would be to replace both A.jar and B.jar with unsigned
versions. But, we then often run into a transitive entanglement. B.jar
may contain classes from package org.jboss, but also org.hibernate. So,
you have to have unsigned versions of C.jar and D.jar that contain the
hibernate packages. But, they have an org.apache package, and so on.
Using TattleTale with some custom reports, I generated "signed jar
groups" identifying clusters of jars that would need to all be replaced
as unsigned if any one is unsigned. For the largest group, I created a
graph of the dependencies shown in
http://community.jboss.org/wiki/SignedJarDependenciesExample
(getopt_jar_Group.png, named by the first jar listed in the group from
the report.)
The figure shows the jars with a line connecting them if they have one
or more packages in common (I also generate detailed plots with a
labelled line for each package in common if anyone wants to see them,
but for the "getopt" group, the detailed plot is quite large and hard to
read.) Clearly, lots of unrelated jars are wound up in this group.
But, we can chip away at this with a bit of analysis. I'll give three
examples.
First, consider the set of jar files just to the right of the center
grouped around jboss-ejb3-core.jar. This set of jars is tied into the
rest of the graph through the connection between
jboss-as-ejb3-deployer.jar and jboss.jar. The package that ties them is
org.jboss.as.javaee. In this case there appears to be only two classes
involved. In jboss.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleIdentifier and in
jboss-as-ejb3-deployer.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleInformer (which has an inner
class). So, in this case, we can break off a chunk of the signed jar
group by, for example, changing a package name:
org.jboss.as.javaee.ejb3.SimpleJavaEEModuleInformer
Next, from the graph, we can see that there is a group of jar files on
the far left that is tied in by a connection between the
jboss-system-jmx.jar and the jboss.jar. In this case, the package is
org.jboss.deployment. There are several classes in jboss.jar and a
handful in jboss-system-jmx.jar that are in this package. So, options
might include renaming the package for the classes in the
jboss-system-jmx.jar, moving them to jboss.jar, or separating the
org.jboss.deployment classes between them into a new jar:
jboss-deployment.jar.
Finally, staying on the far left of the graph we see that run.jar and
shutdown.jar are tied into some third party jars such as getopt.jar,
hsqldb.jar and jdom-1.0.jar. These are due to use of classes in the
default package. Further, the default package is included because the
contents of the getopt.jar are incorporated into run.jar and
shutdown.jar. So, this connection to third party jars can be broken out
by removing the GetOpt related classes from run.jar and shutdown.jar and
relying on the Class-Path: attribute in their manifests.
So, in the end, it would seem to be beneficial to refactor package
locations such that there is not such widespread entanglement. From the
signed jar perspective, it would be best if each package only appeared
in one jar. Of course, there are often engineering reasons to separate
classes in the same package into different jars. However, I think it's
not unreasonable that these should be relatively small in number and
they should be functionally coherent. At any rate, it would appear to
be something we could attack incrementally as indicated by the three
examples above.
Originally, when discussing this with other folks, we thought perhaps we
should just open jiras to address the problem. But, on considering
that, it seemed that perhaps a discussion on a larger game plan would be
a better approach, even if it just ended up with the original plan of
opening some jiras to "chip away" at the problem.
So, I apologize for a long, dense note. For those of you that made it
through, any thoughts, suggestions?
It really boils down to
https://jira.jboss.org/jira/browse/JBAS-1796
See Adrian's comments on the issue.
The latest Tattletale release have support for both Ant and Maven style build
environments, so its up to the project leads to integrate the tool into their
environment and start looking at the dependencies. The latest release also
features the ability to filter 'incorrect' results, so getting clean reports
should be doable.
I have added
https://jira.jboss.org/jira/browse/TTALE-89
which could help to identify how JARs better could be split into a better
structure - still open though. Feel free to hack away :)
For now, I would say if you have certain requirements just open JIRAs for the
projects in question - or better: create a forum thread in the projects
developer forum.
Best regards,
Jesper
11:11 a.m.
On 02/25/2010 01:46 AM, Jesper Pedersen wrote:
Hey Mike,
Hi all,
And down we go... :-)
On Wednesday 24 February 2010 17:50:22 Mike Clark wrote:
> 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.
>
> So, let me start with a description of the problem. Essentially, the
> core issue is around the simple replacement of an EAP signed jar with an
> unsigned jar. While we have a system in place to have QE get one-off
> patches signed in a relatively responsive manner, we are still left with
> cases such as a diagnostic jar created by support to track down
> problems, or a customer that, understanding that it would not be
> supported, wishes to make a change for their system (one of the
> advantages of OSS, of course).
>
> 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. Now, the first step to
> resolve this would be to replace both A.jar and B.jar with unsigned
> versions. But, we then often run into a transitive entanglement. B.jar
> may contain classes from package org.jboss, but also org.hibernate. So,
> you have to have unsigned versions of C.jar and D.jar that contain the
> hibernate packages. But, they have an org.apache package, and so on.
>
> Using TattleTale with some custom reports, I generated "signed jar
> groups" identifying clusters of jars that would need to all be replaced
> as unsigned if any one is unsigned. For the largest group, I created a
> graph of the dependencies shown in
> http://community.jboss.org/wiki/SignedJarDependenciesExample
> (getopt_jar_Group.png, named by the first jar listed in the group from
> the report.)
>
> The figure shows the jars with a line connecting them if they have one
> or more packages in common (I also generate detailed plots with a
> labelled line for each package in common if anyone wants to see them,
> but for the "getopt" group, the detailed plot is quite large and hard to
> read.) Clearly, lots of unrelated jars are wound up in this group.
> But, we can chip away at this with a bit of analysis. I'll give three
> examples.
>
> First, consider the set of jar files just to the right of the center
> grouped around jboss-ejb3-core.jar. This set of jars is tied into the
> rest of the graph through the connection between
> jboss-as-ejb3-deployer.jar and jboss.jar. The package that ties them is
> org.jboss.as.javaee. In this case there appears to be only two classes
> involved. In jboss.jar there is
> org.jboss.as.javaee.SimpleJavaEEModuleIdentifier and in
> jboss-as-ejb3-deployer.jar there is
> org.jboss.as.javaee.SimpleJavaEEModuleInformer (which has an inner
> class). So, in this case, we can break off a chunk of the signed jar
> group by, for example, changing a package name:
> org.jboss.as.javaee.ejb3.SimpleJavaEEModuleInformer
>
> Next, from the graph, we can see that there is a group of jar files on
> the far left that is tied in by a connection between the
> jboss-system-jmx.jar and the jboss.jar. In this case, the package is
> org.jboss.deployment. There are several classes in jboss.jar and a
> handful in jboss-system-jmx.jar that are in this package. So, options
> might include renaming the package for the classes in the
> jboss-system-jmx.jar, moving them to jboss.jar, or separating the
> org.jboss.deployment classes between them into a new jar:
> jboss-deployment.jar.
>
> Finally, staying on the far left of the graph we see that run.jar and
> shutdown.jar are tied into some third party jars such as getopt.jar,
> hsqldb.jar and jdom-1.0.jar. These are due to use of classes in the
> default package. Further, the default package is included because the
> contents of the getopt.jar are incorporated into run.jar and
> shutdown.jar. So, this connection to third party jars can be broken out
> by removing the GetOpt related classes from run.jar and shutdown.jar and
> relying on the Class-Path: attribute in their manifests.
>
> So, in the end, it would seem to be beneficial to refactor package
> locations such that there is not such widespread entanglement. From the
> signed jar perspective, it would be best if each package only appeared
> in one jar. Of course, there are often engineering reasons to separate
> classes in the same package into different jars. However, I think it's
> not unreasonable that these should be relatively small in number and
> they should be functionally coherent. At any rate, it would appear to
> be something we could attack incrementally as indicated by the three
> examples above.
>
> Originally, when discussing this with other folks, we thought perhaps we
> should just open jiras to address the problem. But, on considering
> that, it seemed that perhaps a discussion on a larger game plan would be
> a better approach, even if it just ended up with the original plan of
> opening some jiras to "chip away" at the problem.
>
> So, I apologize for a long, dense note. For those of you that made it
> through, any thoughts, suggestions?
>
>
It really boils down to
https://jira.jboss.org/jira/browse/JBAS-1796
See Adrian's comments on the issue.
This has little to do with JBAS-1796. It's simply a package namespace
conflict which is not allowed in a signed jars environment. This was
expected.
In essence both classes are in the wrong package, because the different
modules should only govern their own namespace. So the proper solution
would be to move org.jboss.as.javaee.SimpleJavaEEModuleIdentifier to
org.jboss.as.server.javaee and
org.jboss.as.javaee.SimpleJavaEEModuleInformer to org.jboss.as.ejb3.javaee.
For the moment lets only do the later.
What is part of JBAS-1796 is the fact that some modules are unscoped and
bleed left and right.
We really need to hack apart the modules, so that we're forced to create
the proper integration points.
In essence we have a base runtime (Reloaded) that allows modules to run
on their own with possible mocks in place.
Carlo
The latest Tattletale release have support for both Ant and Maven
style build
environments, so its up to the project leads to integrate the tool into their
environment and start looking at the dependencies. The latest release also
features the ability to filter 'incorrect' results, so getting clean reports
should be doable.
I have added
https://jira.jboss.org/jira/browse/TTALE-89
which could help to identify how JARs better could be split into a better
structure - still open though. Feel free to hack away :)
For now, I would say if you have certain requirements just open JIRAs for the
projects in question - or better: create a forum thread in the projects
developer forum.
Best regards,
Jesper
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:33 p.m.
Hey Jesper,
On 02/24/2010 06:46 PM, Jesper Pedersen wrote:
The latest Tattletale release have support for both Ant and Maven
style build
environments, so its up to the project leads to integrate the tool into their
environment and start looking at the dependencies. The latest release also
features the ability to filter 'incorrect' results, so getting clean reports
should be doable.
I have added
https://jira.jboss.org/jira/browse/TTALE-89
which could help to identify how JARs better could be split into a better
structure - still open though. Feel free to hack away :)
I've been meaning to circle back and investigate getting these "signed
jar group" reports into tattletale. Just haven't found the time to
start the conversation yet. By the way, great work on tattletale.
Would have been difficult to do the analysis I've done so far without
it. Quite a handy tool.
For now, I would say if you have certain requirements just open JIRAs
for the
projects in question - or better: create a forum thread in the projects
developer forum.
Yes, I think this will be the most likely approach to the refactoring.
Take it a bit at a time with specific jiras.
Best regards,
Jesper
Cheers,
Mike C.
2:27 p.m.
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/classloade...
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.
--
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx
3:44 p.m.
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/classloade...
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.
3:49 p.m.
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/classloade...
> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:58 p.m.
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/classloade...
>> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:01 p.m.
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/classloade...
>>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
5:24 a.m.
You are right, Brian. Split packages across jars works as long as they
are both
signed by the same certificates. We have seen signed and unsigned jars
with packages split across them does not work in the JVM.
Our goal should be to reduce package splitting across jars as much as
possible.
We need to be aware of the packages/jars combination via tattletale such
that
we can sign the jars and do not miss any jars that may have split packages.
On 02/25/2010 09:01 AM, Brian Stansberry wrote:
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/classloade...
>>>> 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.
>>>>
>>>>
4:12 p.m.
On Thu, 2010-02-25 at 08:44 -0600, 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,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)
Right, ok. I didn't know this check existed. The only place it seems
to be mentioned is in the javadoc? See the throws SecurtiyException.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html#define...
One possible workaround solution would be to allow you to somehow
specify that the unsigned jar should create its own local package.
i.e. instead of searching the ClassLoaderDomain for the existing package
you just create one locally.
e.g.
protected void definePackage(String className, URL codeSourceURL)
{
String packageName =
ClassLoaderUtils.getClassPackageName(className);
if (packageName.length() == 0)
return;
// Ask the policy for the information
PackageInformation pi =
policy.getClassPackageInformation(className, packageName);
// Already defined?
Package pkge = null;
if (policy.isSharePackage(packageName))
pkge = getPackage(packageName);
else
pkge = getPackageLocally(packageName);
if (pkge != null)
//etc.
Cheers,
Mike C.
--
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx
6:17 p.m.
On 02/25/2010 09:12 AM, Adrian Brock wrote:
On Thu, 2010-02-25 at 08:44 -0600, 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,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)
Right, ok. I didn't know this check existed. The only place it seems
to be mentioned is in the javadoc? See the throws SecurtiyException.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html#define...
One possible workaround solution would be to allow you to somehow
specify that the unsigned jar should create its own local package.
i.e. instead of searching the ClassLoaderDomain for the existing package
you just create one locally.
Out of curiosity, is there a reason we don't do this already (i.e. a javaee
spec or something)? I'd think that by default each JAR should have a
separate package space, but I guess there could be exceptions in certain cases.
- DML
6:43 p.m.
On Thu, 2010-02-25 at 11:17 -0600, David M. Lloyd wrote:
> One possible workaround solution would be to allow you to
somehow
> specify that the unsigned jar should create its own local package.
> i.e. instead of searching the ClassLoaderDomain for the existing package
> you just create one locally.
Out of curiosity, is there a reason we don't do this already (i.e. a javaee
spec or something)? I'd think that by default each JAR should have a
separate package space, but I guess there could be exceptions in certain cases.
Package sealing wouldn't work. It would see them as two
separate packages.
- DML
--
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx
7:25 p.m.
On 02/25/2010 11:43 AM, Adrian Brock wrote:
On Thu, 2010-02-25 at 11:17 -0600, David M. Lloyd wrote:
>> One possible workaround solution would be to allow you to somehow
>> specify that the unsigned jar should create its own local package.
>> i.e. instead of searching the ClassLoaderDomain for the existing package
>> you just create one locally.
>
> Out of curiosity, is there a reason we don't do this already (i.e. a javaee
> spec or something)? I'd think that by default each JAR should have a
> separate package space, but I guess there could be exceptions in certain cases.
>
Package sealing wouldn't work. It would see them as two
separate packages.
Isn't that a good thing? Or are split packages a lot more pervasive than I
thought? Packages are usually sealed with respect to a single JAR anyway,
aren't they?
- DML
7:59 p.m.
On Thu, 2010-02-25 at 12:25 -0600, David M. Lloyd wrote:
On 02/25/2010 11:43 AM, Adrian Brock wrote:
> On Thu, 2010-02-25 at 11:17 -0600, David M. Lloyd wrote:
>>> One possible workaround solution would be to allow you to somehow
>>> specify that the unsigned jar should create its own local package.
>>> i.e. instead of searching the ClassLoaderDomain for the existing package
>>> you just create one locally.
>>
>> Out of curiosity, is there a reason we don't do this already (i.e. a javaee
>> spec or something)? I'd think that by default each JAR should have a
>> separate package space, but I guess there could be exceptions in certain cases.
>>
>
> Package sealing wouldn't work. It would see them as two
> separate packages.
Isn't that a good thing? Or are split packages a lot more pervasive than I
thought? Packages are usually sealed with respect to a single JAR anyway,
aren't they?
I don't understand your question?
Why is it a good thing to break to break this security feature? :-)
The purpose of sealing a package is to stop somebody else
in the same visible classloading space from adding to your package.
If each deployment used its own package space there would be no way
to enforce it - except when the two jars are in the same
deployment/classloader and hence shared the same package object.
- DML
--
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx
8:11 p.m.
On 02/25/2010 12:59 PM, Adrian Brock wrote:
On Thu, 2010-02-25 at 12:25 -0600, David M. Lloyd wrote:
> On 02/25/2010 11:43 AM, Adrian Brock wrote:
>> On Thu, 2010-02-25 at 11:17 -0600, David M. Lloyd wrote:
>>>> One possible workaround solution would be to allow you to somehow
>>>> specify that the unsigned jar should create its own local package.
>>>> i.e. instead of searching the ClassLoaderDomain for the existing package
>>>> you just create one locally.
>>>
>>> Out of curiosity, is there a reason we don't do this already (i.e. a
javaee
>>> spec or something)? I'd think that by default each JAR should have a
>>> separate package space, but I guess there could be exceptions in certain
cases.
>>>
>>
>> Package sealing wouldn't work. It would see them as two
>> separate packages.
>
> Isn't that a good thing? Or are split packages a lot more pervasive than I
> thought? Packages are usually sealed with respect to a single JAR anyway,
> aren't they?
I don't understand your question?
Why is it a good thing to break to break this security feature? :-)
The purpose of sealing a package is to stop somebody else
in the same visible classloading space from adding to your package.
If each deployment used its own package space there would be no way
to enforce it - except when the two jars are in the same
deployment/classloader and hence shared the same package object.
My understanding is that if the Packages are not equal, then
package-protected access checks across JAR boundaries would fail, which is
what we'd want. I.e. you're strengthening security, not weakening it.
The JVM spec says "Each such class or interface belongs to a single runtime
package. The runtime package of a class or interface is determined by the
package name and defining class loader of the class or interface." which I
take to mean Package object, since Package objects are unique per
classloader. So you'd have one classloader per JAR with completely
segregated Package spaces, possibly within the same domain, thus allowing
individual JARs to be sealed.
Perhaps I've missed something in the conversation though, it wouldn't be
the first time.
- DML
8:23 p.m.
On Thu, 2010-02-25 at 13:11 -0600, David M. Lloyd wrote:
My understanding is that if the Packages are not equal, then
package-protected access checks across JAR boundaries would fail, which is
what we'd want. I.e. you're strengthening security, not weakening it.
The JVM spec says "Each such class or interface belongs to a single runtime
package. The runtime package of a class or interface is determined by the
package name and defining class loader of the class or interface." which I
take to mean Package object, since Package objects are unique per
classloader. So you'd have one classloader per JAR with completely
segregated Package spaces, possibly within the same domain, thus allowing
individual JARs to be sealed.
No. Even if they are in the same physical package, you can't use
package private access across classes defined in
different classloaders.
That used to be an FAQ in early JBoss-3.0.x when every subdeployment
got its own classloader. ;-)
See for example:
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-March/000...
discussing and dismissing a proposal to change that rule.
Whether sealing has any other security benefits I don't know?
But I'd be loath to weaken the checking on somebody's **guess** that
it does not. ;-)
Perhaps I've missed something in the conversation though, it
wouldn't be
the first time.
- DML
--
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx
5170
days inactive
5175
days old
jboss-development@lists.jboss.org
16 comments
8 participants
participants (8)
-
Adrian Brock -
Anil Saldhana -
Brian Stansberry -
Carlo de Wolf -
David M. Lloyd -
Dimitris Andreadis -
Jesper Pedersen -
Mike Clark