[icedtea-web] URLPermission in Java 8

[Jiri Vanek]

On 06/18/2014 05:53 PM, Andrew Azores wrote:
> On 06/18/2014 10:59 AM, Jiri Vanek wrote:
>> On 06/18/2014 04:03 PM, Andrew Azores wrote:
>>> Hi,
>>>
>>> There's a new permission in Java 8 known as URLPermission [0]. It's used to restrict access to,
>>> well, URL resources. Some of our manual test case applets are affected by this, for example,
>>> Oasis [1].
>>>
>>
>> Thank you very much for investigations.
>>
>>> I can't find any documentation on how exactly Oracle grants applets URLPermissions, eg what kind of
>>> path they're allowing the applets to access, or which HTTP methods and headers they may use, etc. So
>>> determining sane defaults on these is the primary point of discussion for this thread. We could just
>>> try to ask Oracle what they're granting as well and mirror that.
>>
>> The Oracle NEVER EVER responded to any of my emails about unclear specification. I even twice
>> tried "directly to person" email, and no reply. So I would gave up here. But you may have more
>> luck :)
>
> Yea, I remember this :/ it's probably worth trying again but not expecting a response.
>
>>
>> I would say to grant all URL permissions  and be happy. W can not afford more "proprietary plugin
>> is running this applet , why is ITW not ?" And perhaps restrict it later if needed.
>
> Well, I don't want to let it be too relaxed to begin with, because that just leaves openings for
> applets to do things we probably don't want them to do.

Well signed applet can do anything it wont anyway.
And unsigned applet is restricted to use network by its nature of "sandboxed one", isnt it?

>
>>
>>>
>>> To confirm that Oasis is impacted by this new permission:
>>> (1) (using openjdk7) Build IcedTea-Web.
>>> (2) Launch browser from terminal
>>> (3) Go to Oasis URL
>>> (4) Observe that applet launches successfully
>>> (5) system-switch-java to openjdk8
>>> (6) Repeat 1-3 and observe that Oasis no longer launches due to SecurityExceptions from missing
>>> URLPermissions
>>>
>>> As a sort of proof of concept, I've attached a small patch. Applying this patch to HEAD and
>>> repeating the Oasis test procedure with Java 8 in use should allow Oasis to run again. This patch
>>> can't compile with Java 7, however, and is also probably too lenient about the URLPermission it's
>>> granting, which allows any request method with any headers to any resource recursively and
>>> inclusively in the applet codebase. So the second point of discussion for this thread is how to
>>> resolve actually adding this permission to the default sandbox permission set.
>>>
>>> [0] http://docs.oracle.com/javase/8/docs/api/java/net/URLPermission.html
>>> [1] https://oasisweb.uga.edu/oasis.html
>>
>>
>> Jsut implementation note - does it have sense to have itw compiled by 7, running on 8? I would say
>> it have sense. Then reflection will have to come to word:(
>> If it do not have sense, we can use same trick as for jdk7 trust manager.
>>
>>
>>
>> Thanx again,
>> J.
>>
>
> If we go with reflection then we should be a little extra careful about it.
> SecurityDesc#getSandboxPermissions gets called *a lot*. Add a print statement and run Oasis and see

Thank you for bringing this up.

> how many times it comes up. We should at least avoid having to do the class lookup on each call,
> unless we trust that on every JVM the class lookup will be cached by the classloader (probably not a
> safe bet). I can't say I have a well informed opinion about using reflection vs the Trust Manager
> Trick though.


Nor do I :)