Icedtea-web bugs

[Jiri Vanek]

Hi Michael!

Do you mind to start PR with the changes you suggest please, and copy the explanation you provided here?
Thus the PR can be now reviewd, and merged. The automagical *all permissions* are dangerous. This
chnge hoewever looks correct (http://openjdk.java.net/jeps/220), unless jrt can be used to load
custom modules, which imho it can be. However, itw do nos support moduel path now, so *now* itloosk
good, but once main JDK will be modular JDK, it will stop to be.

So the test must be provided, which will from unsigned (or with limited permissions) application,
try to load module via jrt, and the loaded module must have same sandbox as caller.

Thanx!

btw - is your issue resolved by this? I got a bit lsot in your requests. They all seems valid, but
are chaging directions. I was sick for somew time, so the question if I shoudl return to the trhead.


Thanx a lot.
  J.
On 4/24/19 2:52 AM, Michael Pritt wrote:
> 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
> 
>  
> 
>  
> 
>  
> 


-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek at redhat.com    M: +420775390109