Dennis Reedy wrote:
Chris, Dennis & Greg, your all spot on with the Service-spec.jar, I'd like to
add something to the jar Manifest of these Service Interfaces, to ensure River
loads it into the top level ClassLoader. Any suggestions?
Why not just support the convention instead of adding configuration?
Ok.
There is one Security Concern that I will have to address with this
Approach:
ClassLoader Structure:
System ClassLoader
|
Extension ClassLoader (incl jsk-policy.jar)
|
Jini Platform ClassLoader (incl jsk-platform.jar, *-api.jar)
|
_______________|________________
| |
Application ClassLoader Proxy ClassLoader's
The *-api.jar files will be placed into Jini Platform ClassLoader, so
the only files visible will be the jini platform classes, java platform
classes and any other *-api.jar classes.
The *-api.jar classes will have their own ProtectionDomain's without any
Permissions.
However this isn't enough to protect us from code that might be included
in the *-api.jar's that use the calling Threads Permissions to perform
security violating actions.
Due to these security concerns, we need to place some restrictions on
the API classes:
1. They must not be allowed to depend on anything other than Jini,
Java Platform and other Service-api.jar's
2. They must not be allowed to depend on any Platform classes that
could cause a Security Violation.
The Service API code really needs to be verified before loading, to
ensure that it does not utilise any platform classes that perform
security sensitive operations.
The ClassDep tool can run a Dependency Analysis on any *-api.jar to
ensure that no security sensitive classes are accessed, prior to loading.
There is some residual risk that as the Java platform evolves, new
classes that perform Security Sensitive actions will be added, which
means the list of restricted classes will need to grow over time.
Could the list itself be contained in a Maven Repository, we could sign,
such a list.
Thoughts?
Peter.
