JOGL Applet Security

[Ken Russell]

I'm sorry, but I don't think I can help you. You should read some tutorials on Java and Java Web Start and come back when you have a more complete understanding of the deployment process.

[camac]

I am increasingly disappointed to see that Java WebStart has become the de-facto deployment solution for Jogl-based applications. For Java applications and games, WebStart may be a reasonable choice, but I for one would still like to see the power of OpenGL available to Java applets. I am an educator, and a firm believer that Java applets embedded in a host web page that supplies the desired instructional context are an effective pedagogical tool. By forcing the application to open in a separate window,  WebStart destroys the tight integration between computer exercise and the surrounding context that is vital to the educational value of the piece. This is exacerbated by the distraction of having to negotiate multiple dialogs before the exercise can actually begin. When you consider that having three or four applets per web page is not unusual, you are left with a deployment solution that is at best impractical for this intended use. If there are workarounds for these problems using WebStart, I'd be glad to hear them; otherwise, let's admit that Jogl applets are desireable for some developers and stop pretending that WebStart is the answer to all deployment scenarios. For the future of Jogl (and, yes, my own selfish interests), I would urge the expert participants of this Forum to undertake a serious effort to provide alternatives.

[princec]

It's pretty tricky to do what's required inside the context of a browser but not impossible. The steps involved are thusly:

1. You must have a fully signed applet.
2. The applet, on first run, needs to create a directory in some well-known but interference-proof location. I would recommend ${user.home}/appletname/native.
3. The DLLs are copied into there from their source jars
4. The Java-side code needs to be able to call System.loadLibrary(System.getProperty("user.home")+"/"+appletname+"/"+native+"/jogl.dll") or something. Therefore JOGL (and LWJGL) would need a few subtle adjustments to allow them to load from custom paths.

It's not actually all that ugly a solution. I plan to try something along these lines myself to get Ultratron working in a browser.

Cas

Games published by our own members! Check 'em out!

[d3]

1. You must have a fully signed applet.
2. The applet, on first run, needs to create a directory in some well-known but interference-proof location. I would recommend ${user.home}/appletname/native.
3. The DLLs are copied into there from their source jars
4. The Java-side code needs to be able to call System.loadLibrary(System.getProperty("user.home")+"/"+appletname+"/"+native+"/jogl.dll") or something. Therefore JOGL (and LWJGL) would need a few subtle adjustments to allow them to load from custom paths.

it s not completely true what you re saying, cas. the applet itself doesn t need to be signed. check out this applet we threw together.

http://www.wortwechsel.biz/kindergarten/gestalt/

the thing is, you need the files installed as extensions in your VM to run this unsigned applet.
to achieve that we wrote an installer, which btw needs to be a signed applet, that installs all necessary files in your VM.
we plan to release the installer as a more general solution, for all kinds of extensions.

the basic idea is to ask the java enabled browser about the location of the VM it uses and then copy the stuff there. on OS X this works pretty nice because the extension policy is very clear. on windows it usually works. the good thing is you one only has to install the extension once.

cheers
d3

[princec]

Installation of shared files for applets can only lead to trouble. I'd be pretty miffed if something got installed in lib/ext that I didn't explicitly put there myself - it's a source of many evil things. Besides, you still need to sign the installer, so why not just instead sign your applet and do it like I said, and all will be well, in all circumstances...?

Cas

[Ken Russell]

It's pretty tricky to do what's required inside the context of a browser but not impossible. The steps involved are thusly:

1. You must have a fully signed applet.
2. The applet, on first run, needs to create a directory in some well-known but interference-proof location. I would recommend ${user.home}/appletname/native.
3. The DLLs are copied into there from their source jars
4. The Java-side code needs to be able to call System.loadLibrary(System.getProperty("user.home")+"/"+appletname+"/"+native+"/jogl.dll") or something. Therefore JOGL (and LWJGL) would need a few subtle adjustments to allow them to load from custom paths.

It's not actually all that ugly a solution. I plan to try something along these lines myself to get Ultratron working in a browser.

Cas

I think this general approach is a good one. It is too bad the Java Plug-In doesn't simply share the Java Web Start jar cache though I think this is a targeted feature for Dolphin. I think it should be possible to write a JOGLApplet or LWJGLApplet class which would be bundled in with the signed JOGL or LWJGL jar file which would allow unsigned applets which subclass these classes to be unsigned. The target applet could be passed as a command-line parameter to the JOGLApplet or LWJGLApplet class which (being signed) could then manually download and execute the target applet in a new class loader. Maintaining proper security for the target applet might be an issue. I think this would be a pretty cool trick to work around the current limitations of the Plug-In. Cas, if you make any progress in this area please post about it.

[camac]

Doing the installation from within an applet is not necessary, at least not for me. I am satisfied if the applet simply detects the absence of the necessary files, then directs the user to a site where the user can download and execute an easy-to-use program that will install those files under his/her full supervision. After all, the installation only has to be done once, after which all applets will run without a hitch.

[Ken Russell]

Doing the installation from within an applet is not necessary, at least not for me. I am satisfied if the applet simply detects the absence of the necessary files, then directs the user to a site where the user can download and execute an easy-to-use program that will install those files under his/her full supervision. After all, the installation only has to be done once, after which all applets will run without a hitch.

This involves dropping the appropriate jar files into the JRE, which is in general a really bad idea since it causes the same kind of "DLL hell" common on Windows. As a community we should probably come up with a solution that works equally well for JOGL and LWJGL as Cas and I suggested above.

[c_lilian]

It's pretty tricky to do what's required inside the context of a browser but not impossible. The steps involved are thusly:

1. You must have a fully signed applet.
2. The applet, on first run, needs to create a directory in some well-known but interference-proof location. I would recommend ${user.home}/appletname/native.
3. The DLLs are copied into there from their source jars
4. The Java-side code needs to be able to call System.loadLibrary(System.getProperty("user.home")+"/"+appletname+"/"+native+"/jogl.dll") or something. Therefore JOGL (and LWJGL) would need a few subtle adjustments to allow them to load from custom paths.

It's not actually all that ugly a solution. I plan to try something along these lines myself to get Ultratron working in a browser.

Cas

I think this general approach is a good one. It is too bad the Java Plug-In doesn't simply share the Java Web Start jar cache though I think this is a targeted feature for Dolphin. I think it should be possible to write a JOGLApplet or LWJGLApplet class which would be bundled in with the signed JOGL or LWJGL jar file which would allow unsigned applets which subclass these classes to be unsigned. The target applet could be passed as a command-line parameter to the JOGLApplet or LWJGLApplet class which (being signed) could then manually download and execute the target applet in a new class loader. Maintaining proper security for the target applet might be an issue. I think this would be a pretty cool trick to work around the current limitations of the Plug-In. Cas, if you make any progress in this area please post about it.

This would be great ! I'm currently implementing this opengl software renderer of mine only to overcome the limitations of applet deployment...  I'm going to check this stuff on windows and mac (I'll try it with the "old" JOGL 1.1.1 code base) and I'll keep you posted on that thread.   

 Lilian

[c_lilian]

Looks promising :

in a simple JOGL applet :

1   2   3   4   5

static {     System.loadLibrary("jawt");     System.load("c:/java/jogl/jogl.dll");  // system dependant loading of dll (should be replaced by user.home/... whatever )    NativeLibLoader.disableLoading();  // disable default library.path loading  }

I've signed the applet and jogl.jar with a temp cert and it works like a charm !

Next step is installing a security manager and create another applet (untrusted this time)... should be harder

Lilian

Games published by our own members! Check 'em out!

[c_lilian]

Could some of you test the following link ?

jogltest

It should start an applet (signed by me) that should install the JOGL natives in a $user.home subdirectory, and show a simple black rect with a small yellow triangle inside...

I've used the same format as JWS (a subdirectory nativelibs at the codebase, and the three native libs in jar format inside)

The next launch should be much faster as the native lib is cached...

I've tested it successfully on MacOs 10.3 and WinXP

Waiting for your feedback !!

Lilian

[turquoise3232]

Hi, works for me witha Win2000 configuration, nice job!

[c_lilian]

Even better !! I've just splited the signed jars in two (signed launcher/ unsigned sub-applet) and guess what ? everything works as expected !

I mean, the security checks are still valid on that unsigned jar (System.setProperty() on that side throws a security exception) and the sub-applet is yet able to create a GLCanvas and invoke open gl from that untrusted side !! There's no need to add a new classloader/security manager.

So with a little refinement, this launcher applet could be part of JOGL (or LWJGL) and benefit from the more trusted Sun certificate...

I'll improve a little bit and post the code (still waiting for other testers...)

Lilian (happy day )

 

[pepijnve]

Works fine on NT4 SP6 with JRE 1.4.2_03
This is definitely a nice solution to the applet deployment problem.

[camac]

Soory to report, the "jogltest" applet did not load for me ( Windows XP). The Java console reported the following errors:

Exception in thread "AWT-EventQueue-4" java.lang.UnsatisfiedLinkError: JAWT_GetAWT0
   at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT0(Native Method)
   at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT(JAWTFactory.java:37)
   at net.java.games.jogl.impl.windows.WindowsGLContext.getJAWT(WindowsGLContext.java:282)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.lockSurface(WindowsOnscreenGLContext.java:167)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:126)
   at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:248)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76)
   at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:236)
   at net.java.games.jogl.GLCanvas.display(GLCanvas.java:77)
   at net.java.games.jogl.GLCanvas.paint(GLCanvas.java:86)
   at sun.awt.RepaintArea.paintComponent(Unknown Source)
   at sun.awt.RepaintArea.paint(Unknown Source)
   at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
   at java.awt.Component.dispatchEventImpl(Unknown Source)
   at java.awt.Component.dispatchEvent(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)
stop
stop
destroy
destroy
applet installer init
starting installer
started!
applet installer async refresh
loading lib C:\Documents and Settings\moyerc\.jogl_ext\1.1.1\jogl.dll
JOGL START
Exception in thread "AWT-EventQueue-5" java.lang.UnsatisfiedLinkError: JAWT_GetAWT0
   at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT0(Native Method)
   at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT(JAWTFactory.java:37)
   at net.java.games.jogl.impl.windows.WindowsGLContext.getJAWT(WindowsGLContext.java:282)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.lockSurface(WindowsOnscreenGLContext.java:167)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:126)
   at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:248)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76)
   at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:236)
   at net.java.games.jogl.GLCanvas.display(GLCanvas.java:77)
   at net.java.games.jogl.GLCanvas.paint(GLCanvas.java:86)
   at sun.awt.RepaintArea.paintComponent(Unknown Source)
   at sun.awt.RepaintArea.paint(Unknown Source)
   at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
   at java.awt.Component.dispatchEventImpl(Unknown Source)
   at java.awt.Component.dispatchEvent(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)
Exception in thread "AWT-EventQueue-5" java.lang.UnsatisfiedLinkError: JAWT_GetAWT0
   at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT0(Native Method)
   at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT(JAWTFactory.java:37)
   at net.java.games.jogl.impl.windows.WindowsGLContext.getJAWT(WindowsGLContext.java:282)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.lockSurface(WindowsOnscreenGLContext.java:167)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:126)
   at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:248)
   at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76)
   at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:236)
   at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:133)
   at java.awt.Component.setBounds(Unknown Source)
   at java.awt.BorderLayout.layoutContainer(Unknown Source)
   at java.awt.Container.layout(Unknown Source)
   at java.awt.Container.doLayout(Unknown Source)
   at java.awt.Container.validateTree(Unknown Source)
   at java.awt.Container.validate(Unknown Source)
   at joglapplet.JOGLAppletInstaller.joglStart(JOGLAppletInstaller.java:165)
   at joglapplet.JOGLAppletInstaller$2.run(JOGLAppletInstaller.java:134)
   at java.awt.event.InvocationEvent.dispatch(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)

[Ken Russell]

Fantastic work! Works well on Windows XP SP1 with 1.5.0_02, on Linux with 1.4.2, and on Mac OS X with 1.4.2. On Linux closing the applet seems to cause the browser to exit though this could be a bug in Mozilla (I'm running an ancient pre-1.0 copy on that machine).

Would you be willing to contribute this to the community under the BSD license?

[c_lilian]

Yes of course...

Let me an hour or two to polish the code and I'd be glad to contribute.

I hope you'll include it (once validated/patched) in the signed jogl.jar.

By the way... where shalI I post the code (here ?)

Lilian

[c_lilian]

I've updated the demo and provided the source code of the JOGLAppletInstaller...

JOGLAppletInstaller.java

Still some work to do to allow better customization... any comments are welcome.

Lilian

[c_lilian]

I've updated the source code to allow access for getAppletContext() from the child applet... haven't tried getCodeBase() yet.

That means applet parameters should work and are transmitted transparently to the child applet.

the new link is here (explanations on the applet behaviour and implementation, demo page and source code.

Any ideas for improvements are welcome..

Lilian

[AK77]

Hi Lilian,
That works! Congrats.

@platform Windows XP SP2/Netscape Browser 8.04 (IE&Firefox)/Java 5 Version 1.5.0 (build 1.5.0_05-b05)

Suggestion: Have the demos in the demo page link to its own applet. -AK⁷⁷

[c_lilian]

Suggestion: Have the demos in the demo page link to its own applet. -AK⁷⁷

I'm sorry I don't understand what you mean ... 

Lilian

[c_lilian]

So now what's the next step Ken ? Will this applet (or an updated form) be added to the jogl.jar in the near future ? That would resolve the whole signing issue and deployement for simple yet powerful applet games...

Lilian

[games]

Thank you very much, however, the applets does not work on my Windows XP.

[tom]

The applet crashed and I get this exception when running the applet:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27

Java vendor: Sun Microsystems Inc. Java version: 1.5.0_02 type 'h' for help -- Image cache enabled Audio cache: enabled ClassLoader cache size: 10 Accept: false java.lang.NoClassDefFoundError: net/java/games/jogl/GLEventListener    at java.lang.ClassLoader.defineClass1(Native Method)    at java.lang.ClassLoader.defineClass(Unknown Source)    at java.security.SecureClassLoader.defineClass(Unknown Source)    at java.net.URLClassLoader.defineClass(Unknown Source)    at java.net.URLClassLoader.access$100(Unknown Source)    at java.net.URLClassLoader$1.run(Unknown Source)    at java.security.AccessController.doPrivileged(Native Method)    at java.net.URLClassLoader.findClass(Unknown Source)    at java.lang.ClassLoader.loadClass(Unknown Source)    at java.lang.ClassLoader.loadClass(Unknown Source)    at java.lang.ClassLoader.loadClassInternal(Unknown Source)    at java.lang.Class.forName0(Native Method)    at java.lang.Class.forName(Unknown Source)    at joglapplet.JOGLAppletInstaller.init(JOGLAppletInstaller.java:107)    at com.opera.PluginPanel.run(PluginPanel.java:441)    at java.lang.Thread.run(Unknown Source)

I'm using Opera.

Btw, can you make the links stand out more in the installer page. I missed the demo the first time because I did not notice the gray "here" text on the bottom of the page.

[c_lilian]

The applet crashed and I get this exception when running the applet:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27

Java vendor: Sun Microsystems Inc. Java version: 1.5.0_02 type 'h' for help -- Image cache enabled Audio cache: enabled ClassLoader cache size: 10 Accept: false java.lang.NoClassDefFoundError: net/java/games/jogl/GLEventListener    at java.lang.ClassLoader.defineClass1(Native Method)    at java.lang.ClassLoader.defineClass(Unknown Source)    at java.security.SecureClassLoader.defineClass(Unknown Source)    at java.net.URLClassLoader.defineClass(Unknown Source)    at java.net.URLClassLoader.access$100(Unknown Source)    at java.net.URLClassLoader$1.run(Unknown Source)    at java.security.AccessController.doPrivileged(Native Method)    at java.net.URLClassLoader.findClass(Unknown Source)    at java.lang.ClassLoader.loadClass(Unknown Source)    at java.lang.ClassLoader.loadClass(Unknown Source)    at java.lang.ClassLoader.loadClassInternal(Unknown Source)    at java.lang.Class.forName0(Native Method)    at java.lang.Class.forName(Unknown Source)    at joglapplet.JOGLAppletInstaller.init(JOGLAppletInstaller.java:107)    at com.opera.PluginPanel.run(PluginPanel.java:441)    at java.lang.Thread.run(Unknown Source)

I'm using Opera.

Btw, can you make the links stand out more in the installer page. I missed the demo the first time because I did not notice the gray "here" text on the bottom of the page.

Strange.. I'll try it with opera tomorrow .. are there known issues with multiple jar files ? the jogl.jar is the second in the list....

And I'll highlight the link

I'll also make an html page with the java plug-in instead of the applet tag, just in case...


Lilian

[c_lilian]

Thank you very much, however, the applets does not work on my Windows XP.

It's may be related to your config, have you specfied in the control panel to use java 1.5 for the applet tag of your brower ?

Lilian

[Ken Russell]

So now what's the next step Ken ? Will this applet (or an updated form) be added to the jogl.jar in the near future ? That would resolve the whole signing issue and deployement for simple yet powerful applet games...

Could you please sign and fax in the Contributor Agreement linked to from the JOGL home page? I'll PM you the fax number.

Once that's done we'll be glad to include this in the standard JOGL distribution. I think it will be fantastic to be able to run JOGL-based applets with no separate installation step necessary (and without interfering with other installations...). We may need some internal security review of the code, etc.

[camac]

This reply is in regard to my earlier post of Nov. 4, reporting that I was unable to load the jogltest applet (unsatisfied link error...). It seems the problem stemmed from my placing the Jogl files in the JRE directories. After removing them, the applet launched sucessfully. This same problem may be confounding other users, since I am sure I am not the only one guilty of putting Jogl files in the JRE.

I'd also like to take this opportunity to thank everyone responsible for this breakthrough, especially Lilian. I am amazed at how quickly the Jogl community responded with an elegant solution to this vexing problem. Congratulations, and keep up the good work!

[tom]

Strange.. I'll try it with opera tomorrow .. are there known issues with multiple jar files ? the jogl.jar is the second in the list....

I did not find any jogl.jar files in the jre directories.

[c_lilian]

This reply is in regard to my earlier post of Nov. 4, reporting that I was unable to load the jogltest applet (unsatisfied link error...). It seems the problem stemmed from my placing the Jogl files in the JRE directories. After removing them, the applet launched sucessfully. This same problem may be confounding other users, since I am sure I am not the only one guilty of putting Jogl files in the JRE.

I'd also like to take this opportunity to thank everyone responsible for this breakthrough, especially Lilian. I am amazed at how quickly the Jogl community responded with an elegant solution to this vexing problem. Congratulations, and keep up the good work!

Thanks ! and great news ! Seems like we'll need to have a "troubleshooting installation" specific to this applet somewhere easily reachable...


There is however still a security issue I'm trying to fix : currently the native libraries are downloaded and installed from the signed part of the applet, but there is nothing granting the native libs are themselves properly signed. So someone could replace them with custom malicious code and bypass the sandbox security.

There are two ways of solving this problem :
1) - adding the native*jars properly signed in the archive list of the applet (that will increase the download size of 200/300kb), and adding the installer code in these jar files.
 That way, the installation will occur only through safe code/signed jar, it's certainly the easiest way.
2) - implementing the verification of the native jar files from the applet installer. 

[edit] I'm not trying the 2) part, too much work... I'd rather use the integrated jar verification provided by 1). Stay tuned, more on this today.


Lilian