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

[Jiri Vanek]

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.