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

Andrew Azores aazores at redhat.com
Fri Jan 10 13:58:55 PST 2014


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.

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
* 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



Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: run_in_sandbox_button.patch
Type: text/x-patch
Size: 25245 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140110/a4178111/run_in_sandbox_button-0001.patch 

More information about the distro-pkg-dev mailing list