[icedtea-web] URLPermission in Java 8

[Andrew Azores]

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.

>
>>
>> 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 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.

Thanks,

-- 
Andrew A