[
https://issues.apache.org/jira/browse/FELIX-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019822#comment-14019822
]
Rob Walker commented on FELIX-4281:
-----------------------------------
Well I got to a better understanding, even if that didn't lead me (yet) to a
more graceful solution
We hit the issue in this part of JNLPClassLoader
{noformat}
//----------------------------------------------------------------------
// CPCallbackClassLoaderIf methods
//
public CodeSource[] getTrustedCodeSources(CodeSource[] sources) {
List list = new ArrayList();
Policy policy = (Policy) AccessController.doPrivileged(new
PrivilegedAction() {
public Object run() {
return Policy.getPolicy();
}
});
for (int i=0; i < sources.length; i++) {
CodeSource cs = sources[i];
boolean trusted = false;
PermissionCollection perms;
perms = policy.getPermissions(cs);
/* Get permissions based on JNLP file that defines code resource */
try {
trusted =
_appPolicy.addPermissions(JNLPClassLoader.getInstance(), perms, cs, true);
{noformat}
That last part I think is trying to add/check a permission for the Extension
url we added to the classpath of the URLClassLoader. This fails because
"http://felix.extensions:9/"; is not a trusted location. I tried seeing if
adding that to the permitted sites configured in Java Control would remove the
error - half expected it would, but for some reason it did not.
Without some way of either marking that URL as trusted, or allowing it's use
untrusted, I suspect our only option is to skip around the Extension manager as
per Karl's mod - with some form of jnlp specific property handling as noted
above.
In passing, I did notice that SecureAction uses a fixed URLClassLoader.class in
the reflection call. This struck me as possibly incorrect. In the JNLP case I
wondered if it would result in the super addUrl() method and not any overloaded
method being called. I'm not exactly sure how using Reflection to overcome
protected method access works - whether it would call the subclass method as
per normal overloading, or just call the super class one.
I adapted the code as follows:
{noformat}
case ADD_EXTENSION_URL_ACTION:
if (arg2 instanceof URLClassLoader)
{
Method addURL =
arg2.getClass().getDeclaredMethod("addURL", new Class[] {URL.class});
addURL.setAccessible(true);
addURL.invoke(arg2, new Object[]{arg1});
}
return null;
{noformat}
I had hoped it may alter the behaviour for this case, but sadly not. Depending
on the reflection handling though, it may be safer coding. JNLPClassLoader does
overload this method in some small way:
{noformat}
protected void addURL(URL url)
{
if (_jclParent != null) {
/* Also in parent... */
_jclParent.addURL(url);
}
super.addURL(url);
}
{noformat}
Whilst this has no major effect, there could be other cases of sub-classes of
URLClassLoader where this would matter.
> Security Warning: Felix with Java Web Start
> -------------------------------------------
>
> Key: FELIX-4281
> URL: https://issues.apache.org/jira/browse/FELIX-4281
> Project: Felix
> Issue Type: Bug
> Environment: Windows 7 with Java 7 update 40, 64 bits
> Reporter: Cesar Souza
> Assignee: Karl Pauls
> Priority: Minor
> Attachments: message.zip, sec_action.patch, viewer.jnlp,
> webstart.patch
>
>
> Since the release of Java 7 update 40 the following warning occurs when you
> try to execute a signed (with valid certificate) Java Web Start application:
> -----------------------------
> Security Warning
> Do you want to run this application?
> An unsigned application from the location below is requesting permission to
> run.
> http://......
> Running unsigned applications like this will be blocked in a future
> release because it is potentially unsafe and a security risk
> -----------------------------
> Although the Java recognizes the certificate in the first dialog, it shows
> the warning message when the Felix's init method is invoked.
> I have tested a same application over Java 7 update 21 and everything is ok.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
