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

[Andrew Azores]

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,

-- 
Andrew A