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

[Andrew Azores]

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,

-- 
Andrew A