Various parties have already pointed out the security concerns with the existing remote
classloading system and the need to better integrate with the AS classloader system.
There are (at least) three points where security is significant to remote classloading.
(1) The loading endpoint needs to be able to control whether or not a given class may be
remotely loaded from a given peer, and by whom. This could possibly be implemented as
some sort of permission, with parameters to specify what range of classes the permission
applies to and what remote services may be loaded from. In addition it might be
beneficial to have a global "off switch" as an easy way to secure an endpoint.
(2) The loading endpoint needs to be able to assign permissions to the loaded class. This
should be doable using the client's security policy mechanism, preferably using some
type of codeBase URL that is able to specify the source of the loaded class.
(3) The endpoint from which the classes are sent needs to be able to restrict the scope of
what classes are made available to the client, so as not to "leak" any
potentially sensitive classes. This could possibly function at a module granularity (JAR
file) or at a package/class granularity.
A quick note - in Remoting 3, classes may conceptually be sent either from client to
server (as part of a request) or from server to client (as part of a reply).
Here's a couple proposals for how to implement it.
(1) A Remote VFS scheme
This solution entails creating a VFS plugin that uses Remoting to load resources
("vfsremote:<remoting-service-URI>" perhaps). A Remoting service would be
created which exports some subset of one system's VFS. A client would then connect to
this service, creating a VFS view of the remote system. Then a classloader which includes
a VFSClassLoader referencing this view is created and injected into the Remoting client
configuration (specifically, as the classloader used by the ClassResolver of the
MarhsallerFactory). This can then be secured by using a VFS codeBase URL (assuming we get
that working, which I'm confident is possible, one way or another).
Pros: very elegant. Uses all our various cool JBoss doodads together. No enhancements to
the Remoting codebase are necessary. No new classloader implementations are needed.
Avoids the various issues that have come up with the current implementation. Uses
standard security configuration. Possibly has other uses outside of remote classloading.
Cons: standalone clients might be very complex, having to include a bunch of our
classloading and VFS stuff in order to gain access to the remote classes/jars/etc. We
would need to devise a way to simplify client configuration as well - maybe even producing
a special API for writing simple clients which preconfigures all this stuff at once.
(2) A RemoteClassLoader implementation
With this solution, we create a ClassLoader implementation which uses a custom remote
classloading service. The server side would wrap one or more ClassLoader instance(s) to
which class lookups are delegated.
Pros: simpler for clients - they'd just have to create a RemoteClassLoader
implementation.
Cons: there are a lot of features in classloaders that do not have a clear mapping across
a remote channel. Getting resources, packages, and security manager considerations all
weigh in to this. I would expect a lot more design bugs with this approach compared to
implementation bugs.
Thoughts?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183976#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...