Icedtea-web bugs

[Michael Pritt]

I see that some changes have gone into the MSI installer so we're looking forward to the 1.8.1 distro.  There are still had some security issues for us, so I've gone ahead and made some changes to our local installation of icedtea-web.  Namely modifying JNLPPolicy.java with changes to the isSystemJar.  I look for the sourceProtocol of "jrt" and return true assuming that this protocol is only for java system libraries.  This allows us to run properly without having to do extra entries into java.policy files.

Wondering if there is a better solution.  I've provided the modification below:

    /**
     * Returns true if the CodeSource corresponds to a system jar. That is,
     * it's part of the JRE.
     */
    private boolean isSystemJar(CodeSource source) {
        if (source == null || source.getLocation() == null) {
            return false;
        }

        // anything in JRE/lib/ext is a system jar and has full permissions
        String sourceProtocol = source.getLocation().getProtocol();
        String sourcePath = source.getLocation().getPath();

        if (sourceProtocol.equalsIgnoreCase("file"))
        {
          final String jreExtPath = jreExtUrl.getPath();
          return sourcePath.startsWith(jreExtPath);
        }

// ************* MY CHANGES ************
       if (sourceProtocol.equalsIgnoreCase("jrt"))
{
    return true; // assuming jrt will only be there for system code...this means we just give all permissions
}
// ********* END OF CHANGES


    return false;

   }

From: Michael Pritt
Sent: Monday, April 22, 2019 7:07 PM
To: IcedTea Distro List <distro-pkg-dev at openjdk.java.net>
Subject: Icedtea-web bugs

Please forgive for sending this out again, but we have not have had a satisfactory resolution, and we felt that perhaps the issue is being lost.  We have been using java's web start for many years.  Recently we have decided to migrate to Java 11 from Java 8 and use IcedTea-web.  No program changes have been made with the exception of what was needed to migrate to Java 11.  It verifies and downloads the jars properly, but when the application runs we get security exceptions.  We are using icedtea-web 1.8 and more specifically installed icedtea-web using the msi installer.

It seems to be a bug when java's web start works, but icedtea-web does not work.  We wonder if there aren't some security changes that have been made from java 8 to java 11 that aren't being adequately handled by icedtea-web.  All our jars are signed correctly.  It looks like that the right permissions are not being set for the internal java classes dealing with security and JNLP.  The security denials are coming when the standard packages like jgss are being loaded and initialized...standard packages like jdk.crypto.cryptoki, java.xml.crypto, jdk.security.jgss, java.smartcardio, etc.

Some of the ouput
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
Denying permission: ("java.security.SecurityPermission" "putProviderProperty.XMLDSig")
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
Denying permission: ("java.lang.RuntimePermission" "loadLibrary.sunmscapi")
Denying permission: ("java.util.PropertyPermission" "sun.security.jgss.native" "read")

Our jnlp file has always specified all permissions and when we sign our libraries (i.e. our jars) they are marked as trusted and requesting all permissions.  Like I said this has been working with java's web start for years.  When we forcefully modify icetea-web's config (i.e. create a java.policy file) and specify that the url is to have all permissions it works (of course that is as it should, but we shouldn't have to do that).

Our second issue is that the desktop shortcut on windows is not created correctly.  The target executable is wrong (path), and the icon is not recognized as specified in the jnlp file.

For both issues we've tested through the browser and by command line and neither work.

If you are already familiar with these issues, and they have resolutions then great perhaps we need to wait for the latest, otherwise please provide us the best way to log a bug and hopefully a resolution can be found.

Thanks,

Mike Pritt



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190424/e95a4277/attachment-0001.html>