[rfc][icedtea-web] (PR1264) Run in Sandbox button

Andrew Azores aazores at redhat.com
Wed Feb 26 09:11:22 PST 2014 

On 02/26/2014 10:05 AM, Jiri Vanek wrote:
> On 02/26/2014 03:48 PM, Andrew Azores wrote:
>> On 02/10/2014 11:25 AM, Andrew Azores wrote:
>>> On 01/27/2014 02:55 PM, Andrew Azores wrote:
>>>> On 01/14/2014 04:26 PM, Andrew Azores wrote:
>>>>> On 01/10/2014 04:58 PM, Andrew Azores wrote:
>>>>>> Hi,
>>>>>>
>>>>>> As inspired by an earlier mailing list thread [1]/[2]/[3], this 
>>>>>> patch introduces a new
>>>>>> "Sandbox" button in the dialog that appears when a user is 
>>>>>> prompted to decide whether or not
>>>>>> they trust the signer of an applet. If the user clicks "Run", 
>>>>>> then the applet proceeds as
>>>>>> normal, being granted full Java Permissions (except in edge cases 
>>>>>> such as PR1592 - mixed JAR
>>>>>> signing - and PR1513 - external main-class). If the user clicks 
>>>>>> "Sandbox", however, the
>>>>>> classloader will treat the applet as if it is completely 
>>>>>> unsigned, and run it only with Sandbox
>>>>>> Permissions, disregarding the fact that the applet has been signed.
>>>>>>
>>>>>> More work will need to be done with this patch once the 
>>>>>> PartiallySigned Dialogs patch goes in,
>>>>>> so that that dialog also supports this action. This will be done 
>>>>>> at a later date in a new
>>>>>> changeset.
>>>>>>
>>>>>> Automated tests have been largely left out of this patch since it 
>>>>>> deals with adding GUI
>>>>>> elements, and the state of the ClassLoader itself cannot be 
>>>>>> directly influenced by a reproducer
>>>>>> without interacting with security prompts (obviously). A small 
>>>>>> unit test was included to check
>>>>>> the conversion between a new AppletAction enum type and arbitrary 
>>>>>> Object references - see the
>>>>>> patch for the relevance of this enum and why this test needs to 
>>>>>> be done.
>>>>>>
>>>>>> Non-automated testing should involve:
>>>>>> 1) running unsigned applets and verifying that the CertWarning 
>>>>>> dialog does not appear
>>>>>> 2) running unsigned applets and verifying that there is no 
>>>>>> Sandbox button
>>>>>> 3) running signed applets and verifying that there is a Sandbox 
>>>>>> button, which is enabled iff
>>>>>> the "always trust content" checkbox is NOT ticked
>>>>>> 4) running signed applets with the "Run" button results in a 
>>>>>> normal applet launch (same
>>>>>> behaviour with and without patch applied)
>>>>>> 5) running signed applets with the "Sandbox" button results in 
>>>>>> the applet not being able to
>>>>>> perform privileged actions
>>>>>>
>>>>>> Some sample signed applets to test with:
>>>>>> a) http://caff.de/applettest/Signed.html - once the applet 
>>>>>> launches, privileged actions include
>>>>>> printing and saving local files. "Sandbox" mode should result in 
>>>>>> permission denied error dialogs
>>>>>> b) https://oasisweb.uga.edu/oasis.html - launch browser from 
>>>>>> terminal to run this test. The
>>>>>> applet will attempt to read several system properties, which it 
>>>>>> will print out. In standard
>>>>>> run, these will be successfully read. In Sandbox mode, permission 
>>>>>> denied errors will be printed
>>>>>> instead.
>>>>>> c) JOGL tests at 
>>>>>> http://jogamp.org/deployment/jogamp-current/jogl-test-applets.html - 
>>>>>> launch
>>>>>> browser from terminal to run this test. Running applets in 
>>>>>> Sandbox mode will cause most of the
>>>>>> applets to fail at runtime, with AccessControlExceptions printed 
>>>>>> to the terminal.
>>>>>>
>>>>>> Known issues (needing discussion):
>>>>>> - The CertWarning dialog sometimes appears more than once for a 
>>>>>> given applet (this is existing
>>>>>> behaviour) - once per certificate that the user needs to approve 
>>>>>> trust. It doesn't seem to make
>>>>>> sense for the "Sandbox" button to only apply to some subset of 
>>>>>> JARs in an applet based on
>>>>>> signers, rather it should simply apply to the entire applet. 
>>>>>> Should further CertWarnings simply
>>>>>> not be shown after the first time, if the Sandbox option is 
>>>>>> chosen the first time? Currently
>>>>>> the implementation sets the entire classloader to Sandbox mode 
>>>>>> when a Sandbox button is
>>>>>> pressed, which *must* occur before any classes are loaded and 
>>>>>> assigned security descriptors, so
>>>>>> pressing Sandbox the first time and Run the second time will 
>>>>>> still result in Sandboxed
>>>>>> behaviour. Or, should subsequent CertWarnings still be shown but 
>>>>>> perhaps with the Run button
>>>>>> disabled if Sandbox has been chosen at least once prior?
>>>>>> - The entire classloader is set to Sandbox mode, and this is not 
>>>>>> done with any more
>>>>>> fine-grained control than this. If multiple applets are sharing 
>>>>>> the same classloader instance,
>>>>>> then they will all be run sandboxed. This can be changed, but I 
>>>>>> think it's going to be a very
>>>>>> rare situation where applets that are sharing a classloader will 
>>>>>> not all be trusted at the same
>>>>>> level by the user. Leaving it as it is keeps the implementation 
>>>>>> simpler.
>>>>>>
>>>>>> ChangeLog:
>>>>>> Added "Sandbox" button to CertWarning dialogs, allowing signed 
>>>>>> applets
>>>>>> to be run with restricted permissions
>>>>>> * netx/net/sourceforge/jnlp/resources/Messages.properties: 
>>>>>> (ButSandbox,
>>>>>> LRunInSandboxError, LRunInSandboxErrorInfo): new messages
>>>>>> * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: (security)
>>>>>> initialize to null when declared. (runInSandbox) new field.
>>>>>> (getRunInSandbox) getter for new field. (setRunInSandbox) set the
>>>>>> classloader to run current applet sandboxed. (activateJars,
>>>>>> initializeResources, addNewJar, setSecurity) assign sandbox 
>>>>>> permissions
>>>>>> regardless of signing if runInSandbox is set. (createInstance) do 
>>>>>> not show
>>>>>> unsigned applet prompt if runInSandbox is set.
>>>>>> * netx/net/sourceforge/jnlp/security/AppVerifier.java:
>>>>>> (checkTrustWithUser) added JNLPClassLoader param
>>>>>> * netx/net/sourceforge/jnlp/security/CertWarningPane.java: added 
>>>>>> Sandbox
>>>>>> button
>>>>>> * netx/net/sourceforge/jnlp/security/JNLPAppVerifier.java:
>>>>>> (checkTrustWithUser) uses AppletAction enum type, calls
>>>>>> JNLPClassLoader#setRunInSandbox if AppletAction is SANDBOX
>>>>>> * netx/net/sourceforge/jnlp/security/PluginAppVerifier.java: same
>>>>>> * netx/net/sourceforge/jnlp/security/SecurityDialogs.java: added
>>>>>> (AppletAction) enum type. (showCertWarning) returns AppletAction
>>>>>> rather than boolean
>>>>>> * netx/net/sourceforge/jnlp/security/VariableX509TrustManager.java:
>>>>>> (askUser) refactor to use AppletAction rather than boolean
>>>>>> * netx/net/sourceforge/jnlp/tools/JarCertVerifier.java:
>>>>>> (checkTrustWithUser) added JNLPClassLoader param
>>>>>> * 
>>>>>> tests/netx/unit/net/sourceforge/jnlp/security/SecurityDialogsTest.java: 
>>>>>>
>>>>>> (testGetIntegerResponseAsAppletAction) new tests for converting 
>>>>>> Object
>>>>>> references into AppletActions
>>>>>>
>>>>>>
>>>>>> [1] 
>>>>>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-October/025394.html
>>>>>> [2] 
>>>>>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-November/025396.html
>>>>>> [3] 
>>>>>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-December/025399.html
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>
>>>>> Again, updating the patches here due to discussions on IRC.
>>>>>
>>>>> Changes since the last set:
>>>>> - There's a new "-Xtrustnone" switch for command-line javaws. This 
>>>>> is like -Xtrustall but rather
>>>>> than choosing the "Run/Proceed" option, the "Sandbox" option is 
>>>>> taken.
>>>>>     - this is used for the new reproducer that is included, which 
>>>>> verifies that the Run in
>>>>> Sandbox button really does reduce the permissions of a signed applet
>>>>> - part of JNLPClassLoader#initializeResources was refactored
>>>>> - the buttons on CertWarningDialogs now have tooltips
>>>>> - Clicking "Sandbox" on a CertWarningDialog causes any subsequent 
>>>>> CertWarningDialogs to not
>>>>> appear, at least not from the same classloader. In the unusual 
>>>>> cases where an applet has
>>>>> multiple classloaders (eg some of the jogl jnlp applets), then 
>>>>> multiple dialogs may still appear.
>>>>>
>>>>> Thanks,
>>>>>
>>>>
>>>> Ping.
>>>>
>>>> Thanks,
>>>>
>>>
>>> Ping... ?
>>>
>>> Thanks,
>>>
>>
>> Ping.
>>
>> Thanks,
>>
>
> This no longer apply to head.

One hunk fails and it was just fixing some formatting/whitespace, so 
that's fine. I've removed that hunk from these new, split patches, so 
they do apply cleanly now.

"implementation" can be applied on its own, but it doesn't actually do 
anything. It essentially just sets up the classloader to be able to run 
applets sandboxed. "dialog" adds the ability to make the classloader do 
this by adding a button for it.

Thanks,

-- 
Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dialog.patch
Type: text/x-patch
Size: 13221 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140226/df241839/dialog-0001.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: implementation.patch
Type: text/x-patch
Size: 11669 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140226/df241839/implementation-0001.patch

More information about the distro-pkg-dev mailing list