Bugzilla – Full Text Bug Listing
|Summary:||Can JWS application security element be tightened?|
|Product:||GridShib||Reporter:||Von Welch <email@example.com>|
|Component:||GridShib-CA||Assignee:||Von Welch <firstname.lastname@example.org>|
Currently the JNLP file for the GridShib-CA client contains the following: <security> <all-permissions/> </security> Question is, can this be tightened? This bug will track my research in this area.
The permissions required by the GS-CA client are: 1) Ability to create a GUI to interact with the user. 2) The ability to open a http socket back to the GS-CA server using a specified set of trusted CAs 3) The ability to create or overwrite the user credential file in a temporary space (/tmp in unix; elsewhere in Windows). 4) Optionally, the ability to download trusted CA certificates for the user: 4a) The ability to create ~/.globus/certificates if it does not exist. 4b) The ability to create or overwrite files in ~/.globus/certificates #1 seems to be granted by default. #2-4 are current granted by the <all-permissions/> element.
According to  there are two options for the security element: <all-permissions/> or <j2ee-application-client-permissions/> However  is unclear on what the permissions granted by <j2ee-application-client-permissions/> are: "J2EE permissions are usually sufficient, since they include socket permissions, clipboard access permission, and printing permission, among a set of ten." According to this post , the permissions granted are (ten permissions, which is consistent with ): java.awt.AWTPermission accessClipboard java.awt.AWTPermission accessEventQueue java.awt.AWTPermission showWindowWithoutWarningBanner java.lang.RuntimePermission exitVM java.lang.RuntimePermission loadLibrary java.lang.RuntimePermission queuePrintJob java.net.SocketPermission connect java.net.SocketPermission localhost:1024- accept, listen java.io.FilePermission read, write java.util.PropertyPermission * read  http://java.sun.com/developer/technicalArticles/Programming/jnlp/  http://forums.sun.com/thread.jspa?messageID=2667170#2667170
Changing the security element to <j2ee-application-client-permissions/> leads to the following error at run-time in the GS-CA client. Running... Warning:Failed to initiate trusted CAs: Unable to create temporary file Generating cryptographic keys... Generating certificate request... Connecting to GridShib-CA server... Fatal Error: access denied (java.lang.RuntimePermission getClassLoader) Press OK to close application getClassLoader is needed to install the trusted CAs for the HTTPS socket. Note the Warning on the second line is another permission I neglected earlier, in that the JWS client must create a temporary file to hold the trusted CAs for the HTTPS connection. Conclusion, there is nothing I can do to tighten the security in the JWS client and still have it function. However it does seem very likely that if custom CA certificates for the HTTPS connection were not required, this might be possible.