felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Walker (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4281) Security Warning: Felix with Java Web Start
Date Fri, 06 Jun 2014 13:12:02 GMT

    [ 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

We hit the issue in this part of JNLPClassLoader

    // 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);

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:
                case ADD_EXTENSION_URL_ACTION:
                    if (arg2 instanceof URLClassLoader)
                        Method addURL = arg2.getClass().getDeclaredMethod("addURL", new Class[]
                        addURL.invoke(arg2, new Object[]{arg1});
                    return null;

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:

    protected void addURL(URL url)
        if (_jclParent != null) {
            /* Also in parent... */

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

View raw message