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

[Andrew Azores]

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,

-- 
Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: run_in_sandbox_button_full3.patch
Type: text/x-patch
Size: 27876 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140114/874c50f5/run_in_sandbox_button_full3-0001.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run_in_sandbox_button_tests.patch
Type: text/x-patch
Size: 18472 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140114/874c50f5/run_in_sandbox_button_tests-0001.patch