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

[Andrew Azores]

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,

-- 
Andrew A