[rfc][icedtea-web] (PR1264) Run in Sandbox button
aazores at redhat.com
Fri Jan 10 13:58:55 PST 2014
As inspired by an earlier mailing list thread //, 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
c) JOGL tests at
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
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.
(checkTrustWithUser) added JNLPClassLoader param
* netx/net/sourceforge/jnlp/security/CertWarningPane.java: added Sandbox
(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
(askUser) refactor to use AppletAction rather than boolean
(checkTrustWithUser) added JNLPClassLoader param
(testGetIntegerResponseAsAppletAction) new tests for converting Object
references into AppletActions
-------------- next part --------------
A non-text attachment was scrubbed...
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