-
1. Re: XPost - Remoting from unsigned applet - ClassLoader secu
Hi James,
The problem in the current state of Remoting is that org.jboss.remoting.AbstractInvoker, the grandparent of all invokers, client and server, starts by creating an org.jboss.remoting.loading.ClassByteClassLoader, which can load a class locally or, if it's not available locally, load it over the network. I'm thinking that the linethis.classbyteloader = new ClassByteClassLoader(this.getClass().getClassLoader());
in AbstractInvoker could be replaced bythis.classbyteloader = getClass().getClassLoader();
[In reality, of course, we would want the classloader to be configurable.]
I've run this by a resident classloader expert who thought it sounded plausible. Now, for me, the problem is that I don't see a big demand for something like this, so, if there are some hidden gotcha's, I probably wouldn't put much time into it. On the other hand, if you experiment with the issue and get it to work, we could look at making the necessary changes to Remoting. It would be easy to make the classloader a configurable parameter, for example. -
2. Re: XPost - Remoting from unsigned applet - ClassLoader secu
Thanks for pointing me in the right direction.
I'll have a play with this over the next few weeks and see how I get on, then get back to you with my findings/questions/code.
regards
James -
-
4. Re: XPost - Remoting from unsigned applet - ClassLoader secu
I finally got round to trying the quick fix you mentioned but got a;
java.lang.ClassCastException: sun.plugin.security.PluginClassLoader cannot be cast to org.jboss.remoting.loading.ClassByteClassLoader
at org.jboss.remoting.AbstractInvoker.(Unknown Source)
at org.jboss.remoting.MicroRemoteClientInvoker.(Unknown Source)
at org.jboss.remoting.RemoteClientInvoker.(Unknown Source)
at org.jboss.remoting.transport.http.HTTPClientInvoker.(Unknown Source)
at org.jboss.remoting.transport.servlet.TransportClientFactory.createClientInvoker(Unknown Source)
.....
which I suppose isn't surprising. You mentioned that ideally the classloader would be configurable. Is there any chance of adding this option in the near future?
regards
James -
5. Re: XPost - Remoting from unsigned applet - ClassLoader secu
D'oh. Don't know what I was thinking.
One of the things I did for the Remoting 2.4.0.GA release was wrap all security sensitive calls inside java.security.AccessController.doPrivileged() calls. Most of these calls go through a SecurityUtility, which currently has 61 methods. Each method is called by one or more places in the Remoting code, so there are dozens of places that could cause security violations.
But now that the work is done, Remoting 2.4.0.GA can run in the presence of a security manager, provided sufficient permissions are granted. There are sample permission files (for the default application security manager) in the distribution, downloadable from
http://www.jboss.org/jbossremoting/downloads .
Also, there is a discussion in Section 5.9. "Running with a security manager" of the Remoting Guide (http://www.jboss.org/jbossremoting/docs/guide/html/index.html).
Now, these changes weren't made with unsigned applets in mind, and I can't tell you a lot about security in unsigned applets. However, it looks like the Applet Java Plug-in starts JVMs that (at least in jdk 1.6) can be configured to run unsigned applets with permissions beyond the classical applet sandbox. In particular, the "JavaTM Network Launching Protocol & API Specification (JSR-56)" version 6.0.10 says
The sandbox environment described above is the default set of permissions granted to an untrusted application or applet. The JNLP Client may allow the user or system administrator to configure alternative permission sets for untrusted applications and applets.
So it sounds like it might be possible, with the right permission configuration, to get Remoting 2.4.0.GA to run in unsigned applets.
James, if you investigate and learn more, I'd like to hear your conclusions.
-Ron -
6. Re: XPost - Remoting from unsigned applet - ClassLoader secu
Hi Ron, I'll make some time to look at this over the next few weeks and report back.
James -
7. Re: XPost - Remoting from unsigned applet - ClassLoader secu
Hi James,
Sounds great. Looking forward to it.
-Ron -
8. Re: XPost - Remoting from unsigned applet - ClassLoader secu
Hi Ron,
I never got a chance to look at this in the end, any ideas how things have changed going to remoting 3? in short, is there an easy way to use remoting 3 from an unsigned applet? if not how to go about it...
Thanks
J
P.S. Regarding the JBoss community site, does anyone have any idea how I set my own password ? How do I update my email address?
-
9. Re: XPost - Remoting from unsigned applet - ClassLoader secu
fatbatman wrote:
Hi Ron,
I never got a chance to look at this in the end, any ideas how things have changed going to remoting 3? in short, is there an easy way to use remoting 3 from an unsigned applet? if not how to go about it...
As long as you're connecting back to the server which served the page, it should work under 3.1+ (however this has not been tested) because R3 does not require any of the actions that are "forbidden" to unsigned applets. Testing might reveal that some things - like reading system properties - might not be appropriately guarded against SecurityExceptions though.
Also the "default" way of creating an endpoint relies on reading system properties so it might be necessary to use the more manual enpoint creation methods ("Remoting.createEndpoint(...)").