[patch] RFC: Netx plugins

[Francis Kung]

Hi,

>>> - need to pass --enable-netx-plugin to enable this (considering it an 
>>> experimental feature); all this does is create netx.jar in 
>>> j2sdk/jre/lib with netx code in it.  If this jar is missing, we fall 
>>> back to using the old Sun plugin code (see the reflection bit in the 
>>> sun.applet.PluginAppletViewer constructor).  I'm creating a new 
>>> netx.jar, instead of using j2sdk/lib/tools.jar (like javaws does), so 
>>> that the plugin can be distributed with a JRE rather than requiring 
>>> the full SDK.
>>
>> Should --enable-netx-plugin be set by default? In my opinion, 
>> everything is experimental. There should only be an option to disable 
>> netx.
> I think it should also be enabled by default. Perhaps the jar name 
> should be something less general than netx.jar though -- perhaps 
> netx-web-plugin.jar ?

I was planning on enabling it by default once it's finished (ie can do 
signed JAR verifying, the remaining TODO/FIXME's done), but I've no major 
objection to enabling it right away - haven't run into any problems in my 
testing... =)

The JAR also contains the full netx code, not just applet/plugin code, 
hence the name, but I have no particular attachment to a name.

>>> - modified the default security policy to grant all permission to 
>>> ${java.home}/lib/netx.jar  (is this safe, or is there a better way to 
>>> accomplish this?)
>>
>> We should never allow a user to allow an application to grant all 
>> permissions. 
> Unless that application is signed and the user trusts the signer and 
> publisher (as is the case with jnlp applications). It probably doesn't 
> apply too well to this situation though, since I don't think we'll be 
> signing that jar.
>> I think we need to make these type of apps as secure as possible and 
>> be sure we ask each time. What about having a whitelist? Also, I don't 
>> think it would be in the best interest to have the default security 
>> policy so lax.
>>
> While it's a good idea to ask each time, won't it be too much to be 
> asking to run netx.jar, then also asking to grant full permission to the 
> actual applet? Further yet, should we want to ask the user for 
> permission to grant all access to ${java.home}/lib/netx.jar, would 
> netx.jar be showing the permission dialog, and then changing the default 
> security policy?

Sorry, I didn't explain this very clearly... here I am referring to the 
security policy set in jre/lib/security/java.policy, granting full 
permission to the code contained in netx.jar - that is, to the Netx code 
itself.  This is completely separate from granting permission to applets.

>>> This isn't complete, but it's finally in a working state and has been 
>>> in a private repo for too long... currently a dialog is displayed for 
>>> all applets asking if the user wants to grant it full permission or 
>>> not.  
>>
>> Is the dialog displayed for each applet or just the first applet is 
>> loaded? if "grant full permissions" is selected, are the permissions 
>> granted for all applets or only that particular one?  I think we 
>> should display if for each applet. (Not sure if I misunderstood the 
>> previous point as well)
> Yes, probably display it for each applet. The above policy is OK, but 
> perhaps it could be improved by letting the user choose what kind of 
> permissions to allow on startup (i.e. file read, file write, clipboard 
> access, etc) or maybe even show dialogs on each type of access, with the 
> option to "always allow this action" for the rest of the applet's 
> runtime? I could imagine this would involve a bit more work though...

Yes, the dialog is displayed for each applet loaded, and permissions are 
per-applet (even refreshing a page, and thus causing an applet to reload, 
will trigger the dialog to display again, and two applets running 
simultaneously can have different permission levels).

Whitelisting applets with a "trust this applet from now on" checkbox is 
on the to-do.

Letting the user choose specific permissions at startup actually wouldn't 
be too difficult; see netx.jnlp.SecurityDesc and how they list the 
permissions for j2ssPermissions and sandboxPermissions - we could create 
a new array customPermissions and populate it at run-time based on GUI 
input... creating the GUI would probably be the most time-consuming part ;-)

>>> The plan is to re-use Josh's work on Netx jar-verifying to tweak this 
>>> dialog and only display it when needed; we can also create a 
>>> consolidated JNLP/plugin settings GUI (cache management, trusted 
>>> certificates, etc).
> Yes, this might be a good idea. I've still yet to figure out how to keep 
> track of who we're trusting in terms of code signers and certificates.

I know web browsers usually have a default set of trusted root 
certificates, used for SSL.  We could either tap into that and use their 
list (we already have a dependency on firefox/mozilla anyways), or maybe 
create our own list based on that...?

>>>
>>> Comments, or good to commit? 
>>
>>
>> Hold off for now. Have you run your patch by fitzsim?

Nope.  If you could ping him to take a look at this list when he's got a 
chance, that's be great =)

Thanks,
Francis