[rfc][icedtea-web] Reflectively add URLPermission to SecurityDesc if available

[Andrew Azores]

On 07/15/2014 12:54 PM, Omair Majid wrote:
> * Andrew Azores <aazores at redhat.com> [2014-07-15 11:44]:
>> On 07/15/2014 11:19 AM, Omair Majid wrote:
>>> * Andrew Azores <aazores at redhat.com> [2014-07-15 11:12]:
>>>> Which part? Just the URLPermission's port, or the downloadHost itself?
>>> The port: it should match the port where the jars were downloaded from.
>> Hmm. Does JNLPFile#getCodebase()#toURI()#normalize()#getPort() sound right?
>> That's what it boils down to in this patch now. I don't know of anywhere
>> where we keep a more explicit reference to the port that was actually used
>> to download the resources, but I suppose that would generally be either that
>> same port, or if not specified, then just the default port for the protocol,
>> so the same thing as this. Right?
> I believe you are correct, but my knowledge of the internals is a bit
> old. Maybe check how that download url for the resource is computed
>
> Thanks,
> Omair
>

Okay, took some digging.

Now the applet's location's host domain is simply assumed to be the host 
part of the resource's location, which should be located somewhere below 
the applet codebase. This host is permuted with the ports from each of 
the applet's associated resources and a set constructed from the 
permutations, then each of the set's members are added to the sandbox 
permission. If a port is not specified then the URLPermission 
documentation says it takes this to mean the default port, at least for 
http(s) schemes - I don't know what happens for eg ftp. No port 
restriction perhaps? It's not clear from the documentation I've seen, 
but I wouldn't expect it to mean the permission has no effect, so I 
suppose it's no port restriction (unfortunately).

So here are some examples of what the results *should* look like in a 
few cases.

Case A - extremely simple, standard applet
codebase = http://example.com/applet
host = http://example.com
resources = [ http://example.com/applet/app.jar ]
permissions = [ http://example.com:80/- ]

Case B - simple applet with multiple jars
codebase = http://example.com/applet
host = http://example.com
resources = [ http://example.com/applet/app.jar, 
http://example.com/applet/lib/applib.jar ]
permissions = [ http://example.com:80/- ]

Case C - applet with resources from explicitly defined ports
codebase = http://example.com/applet
host = http://example.com
resources = [ http://example.com:8080/applet/app.jar, 
http://example.com:9090/applet/lib/applib.jar ]
permissions = [ http://example.com:8080/-, http://example.com:9090/- ]

Case D - resources with different protocols
codebase = http://example.com/applet
host = http://example.com
resources = [ http://example.com/applet/app.jar, 
https://example.com/applet/lib/applib.jar ]
permissions = [ http://example.com:80/-, https://example.com:443/- ]

Case E - resources with different protocols and explicit port
codebase = http://example.com/applet
host = http://example.com
resources = [ http://example.com/applet/app.jar, 
https://example.com:4430/applet/lib/applib.jar ]
permissions = [ http://example.com:80/-, https://example.com:4430/- ]

* Case F - applet with no JARs... not sure what to do about this one
codebase = http://example.com/applet
host = http://example.com
resources = [ http://example.com/applet/app.class ]
permissions = [ ]

Any ideas on what to do for case F? Perhaps as well as iterating over 
all the JARs' locations I should also add the JNLPFile's getCodebase()'s 
host with its default port - but this could end up adding an extra 
permission that shouldn't actually need to be there? And any ideas on 
how to write reproducers for this? Should I just make a simple 
reproducer that attempts to make some bogus connection on a non-default 
port, for example, and check that it fails (this would cover Case A)? 
I've already included some unit tests for the simple URI manipulation 
stuff. I was thinking of adding some tests using dummy JNLP files and 
exposing SecurityDesc#getUrlPermissions() as package-private to be able 
to better test the expected results in the Cases above, but this would 
mean that the SecurityDescTest would also need to do the same reflection 
to determine if URLPermission is available. Should that be done?

Thanks,

-- 
Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: urlpermissions-7.patch
Type: text/x-patch
Size: 15822 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140717/9f58ccbe/urlpermissions-7.patch>