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
anonymous wrote :
| 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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159710#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...