[patch] RFC: Netx plugins

[Lillian Angel]

Hi,

Francis Kung wrote:
> 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.

Ah, makes more sense. Thanks.

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

Great.

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

I think that's safe to do.

>
>>>>
>>>> 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 =)

Yep.


Lillian