"Sun Endorsed" extensions

General Discussions
#21

Ok, I looked into it a bit, and Flash’s 3d support is, indeed, very limited; it sounds like it’s just able to apply perspective correction to textured triangles, and this may be hardware accelerated, but they don’t have a full 3d engine. So you’re right, no direct OpenGL API or anything like that.

I still don’t think I agree, though, that providing OpenGL access would open up a security hole. Is there something I don’t know about JOGL’s API that would permit system pwnage? I’ve never heard of an exploit like that before.

I guess I’m not entirely sure what you mean here. To me, a Java wrapper around OpenGL does turn the underlying native code into an implementation detail. That’s kind of the point of OpenGL, to expose a useful graphics API without forcing you to interface directly with the graphics card. I don’t see any need to break out of the sandbox for that, especially if the native code at the interface is controlled by Sun (which it is, if we’re talking about JOGL).

We may just be arguing different points here, I’m not sure. I agree with Cas, I don’t see any conceivable security hole in exposing the OpenGL API, there’s no route that I know of that allows an OpenGL call to do anything bad to your computer (modulo, of course, a real devious bug in the driver code that accesses the graphics card, which is a totally different issue that shouldn’t be Sun’s concern at all, since it would be someone else’s bug).

At the risk of repeating myself: to force a complete break from the sandbox to achieve something that should be possible from within it is bad bad bad security practice. Without a finer grained security mechanism (which would be all but impossible to phase in at this point in Java’s evolution), the best solution is to directly allow access, even if only in limited form, to the safe bits of functionality that are most commonly used.

#22

You could look at the argument this way: if LWJGL isn’t safe, is Java2D?

Cas :slight_smile:

#23

that boils down to “Did we or someone else build it” ;D ::slight_smile:

Security is only a part of the picture of “does it work?” I’m sure you could find a pragmatic solution to keeping everyone happy. Like having the user select a level of paranoia(PR-department needs to come up with a better word :P) High/Strict - as it is now or medium/Lose - that adds a default list of certificates to the trusted list.

Seems to work for most consumer targeted firewall software…

The advantage of going this route is that you don’t get a split between JVM implementations/distributions between ones that do and do not endorse.

#24

[quote]I still don’t think I agree, though, that providing OpenGL access would open up a security hole. Is there something I don’t know about JOGL’s API that would permit system pwnage? I’ve never heard of an exploit like that before.
[/quote]
hum, I guess probably tens… even being able to switch fullscreen without user agreement could be considered as a security hole. even if it is far to be perfect, browser security have been improved a lot year by year by learning what can annoy the user, in a normal security you should not be able to :

  • switch fullscreen
  • control mouse
  • use too much ressource memory/cpu
  • open multiple window
  • produce error by sending wrong instruction to device (can happen when enabling low level devide access)
  • disable browser close
  • produce fake screen/window => undecorated window
  • change target of a drop (ex : moving a window when mouse up after a drag)
  • etc… etc…

in short , most cool stuff can appear as security hole depending on how coder use it.

[quote]I have to admit I haven’t yet took a look flash but something tells me that you won’t have direct access to apis like OpenGL - if yes sorry but than Flash is the next ActiveX which was almost a synonym for maleware.
[/quote]
probably you will be able soon to get access to a secured interface to perform hardware accelerated stuff but this doesn’t sound flash like to directly program opengl, but it will (it already…) use HW for 3D as for 2D in a secure (not direct) maner for sure.

#25

Fullscreen is a privileged action currently but I notice that Flash doesn’t ask permission to go fullscreen. But it’s not part of the OpenGL bindings anyway.

All I’m saying is, if the source is submitted to Sun, they could give it a thorough security check and then endorse it by signing with a certificate which allows the JVM to load it without any security warnings popping up. As if they’d basically written the code themselves and made it part of the JRE. For something as simple as LWJGL it should be a doddle.

Cas :slight_smile:

#26

[quote]Fullscreen is a privileged action currently but I notice that Flash doesn’t ask permission to go fullscreen. But it’s not part of the OpenGL bindings anyway.
[/quote]
yup seems it dont, also severals plugins dont too, but IMHO it should be requiered because if no, you can produce some kind of “phishing” application : fake window/linux login, fake desktop, it is up to the coders imagination

[quote]All I’m saying is, if the source is submitted to Sun, they could give it a thorough security check and then endorse it by signing with a certificate which allows the JVM to load it without any security warnings popping up. As if they’d basically written the code themselves and made it part of the JRE. For something as simple as LWJGL it should be a doddle.
[/quote]
ok that would be ofsourse really great (but I would really prefer that they make it loadable as an extrnal library not included in the base JRE, this one is already … toooo big also xternal libraries will work with older JVM as it wont requiere lastest JRE, I dont understand why java dont work more that way => provide external libraries and not always increase the base jre)

#27

That phishing stuff… is basically utterly paranoid. If you find yourself visiting the sorts of sites that have applications that can do that - you’re already flirting with trouble anyway. I think the whole issue has gotten out of hand, a bit like the supposed threats of terrorism - that is, the paranoia is now actually far more of a bloody hassle than the actual threat.

Cas :slight_smile:

#28

[quote]That phishing stuff… is basically utterly paranoid. If you find yourself visiting the sorts of sites that have applications that can do that - you’re already flirting with trouble anyway. I think the whole issue has gotten out of hand, a bit like the supposed threats of terrorism - that is, the paranoia is now actually far more of a bloody hassle than the actual threat.
[/quote]
not really you can fall on such website just by clicking on a result in google or by clicking on a link on a digg-like website, I am not paranoid but the money stolen using internet as bank account or credit card number and other is quite huge… and probably a product that dont take care of that and can help doing such thing will get a very bad advertising/publicity for the futur if it happen only once and will be ofcourse forbidden in compagny…

EDIT:

[quote]the paranoia is now actually far more of a bloody hassle than the actual threat.
[/quote]
unfortunatly that’s probably not wrong …

#29

No, but even Java2D is also not considered strictly safe by java’s standards as well (switching full screen will require code signing).
That said, I agree that OpenGL could be considered just as safe as Java2D: No code signing necessary as long as you don’t switch to full screen.

But in principle I believe the security dialog is a Good Thing. It’s good that there is some kind of user feedback that the application requests privileges outside of the sandbox. It has prevented java from becoming the tool of choice for malware and it got java the reputation of being safe, so considering exceptions should always be approached with the greatest care.

#30

The solution here is to do exactly what Flash does - show an overlay that says “Press ESC to exit full screen mode” and then hard code the escape key to do so, without the programmer having any choice in the matter. Also, IIRC the fullscreen mode can only be entered as a result of a user interface action, not a pure programmatic one. These are technical issues, not fundamental security ones.

I think this problem is almost exactly what Cas is addressing - if there was a system in place for an optional second tier of official Sun libraries that didn’t require full sandbox-breaking to run but also didn’t need to be installed with the base JRE, it would allow a lot more modularity.

Absolutely. But not considering exceptions at all is a big problem, too, because it means that things that should be considered sandbox safe now need to be out of the sandbox, which is a security flaw - people should never need to grant permission to their entire system just to allow something to use their graphics card, but under the current model they do.

#31

That’s exactly the problem. Train users to press OK every time a security dialog pops up and the next thing you know, they click OK on everything.

The funny thing about signing, too, is that it only proves a bit of code hasn’t been tampered with by anyone else. There is nothing at all to prevent a fraudster obtaining a certificate and signing phishing code. Nothing. Signed code is not safe. It’s just provably untampered with.

So it’s really all rather pointless as far as the human element of security goes.

Cas :slight_smile:

#32

Of course signed code is not necessarily safe code, but the resulting security dialog is good feedback that this program will run outside of the security sandbox.

Many users might choose to ignore it because they click OK on everything, but imho that doesn’t mean it’s pointless for everyone. That’s not the problem of security dialogs but the problem of the users that ignore them (and of their friends and relatives that have to reinstall their PC for the umpteenth time again :P).
I for one like to know if running some java applet or webstart app requires some additional trust from my side so that I have a choice to run the program or not.

Oh I absolutely agree that the current security model is too coarse, but that’s a bit of a different discussion isn’t it? (I mean, endorsed libraries won’t fix that)

For the record, I do agree with Cas’ proposition. Not so much because security dialogs are pointless, but as a way to make the scope of the security sandbox a bit more flexible, yet still controlled.
But one thing I’m not really confident about is the following scenario:
What if endorsed libraries start showing up, and one version of a library turns out to have a serious security flaw? What would stop dubious parties to keep using this particular version of this library? An expired certificate?

#33

Same way as any other security flaw - JRE gets patched, certificate revoked in the patch.

Cas :slight_smile:

#34

Hm yes, as long as ‘revoked’ doesn’t mean breaking all software using it in the process, but instead having the good-ole security dialog pop-up again…

#35

There are some problems with this though, the message “press escape to …” is localized in the language of Flash Player, which might be a different language from the actual SWF (obviously, but it can look weird to viewers if the whole thing is in Dutch and then this one message is in English).

One thing that you didn’t mention is that the owner of the website needs to add a “allowFullscreen=true” parameter to the embed code. This means that both the owner of the website and the owner of the SWF need to allow fullscreen mode, and only then this becomes possible.