Skip to main content

Why is referencing extension on different host prohibited?

12 replies [Last post]
alexter
Offline
Joined: 2006-11-10

Hello everyone,
This might be a stupid question, but... Why does Web Start refuse to load a jnlp that references a component extension located on another host? The error message is "Multiple hosts referenced in resources"+something about security. Actually these are two questions:
1. What security concern might stand behind that? Even if my application picks up libraries (component extension) from a different host, it still runs in a sandbox, so what's the issue?
2. How does this comply with JNLP spec, which states clearly in section 5.5 ("Untrusted Environment") :The JNLP file can request extensions and JREs from any host. An application cannot make a socket connection back to any of the hosts where JREs or extensions are downloaded from (unless it happens to be the same host as for the JAR files). Extensions requested from hosts other than the one that the JAR files were downloaded from must be signed and trusted as per section 5.4.
That said, I still cannot understand why component extensions are required to be trusted.

Please tell me I'm doing something wrong! Because this behavior is very frustrating. Why not allow widely used components to be hosted in a single place and shared across applications, thus minimizing the download sizes. In this circumstances one has two choices: to either bundle every library with application or always request full-permissions, which makes application unsafe and annoying.

Thanks in advance for any response.
Alex

Message was edited by: alexter

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tackline
Offline
Joined: 2003-06-19

> Withing the JNLPClassLoader, trust is granted to
> CodeSources based on combination of the
> request in the jnlp file containing that resource,
> and the users acceptance of the security dialog based
> on the CodeSigners in that CodeSource. (This is one
> reason all jars in a jnlp file must be signed by the
> same Certificates).

There are much better reasons why all jars should be signed with the same certificate.

Extensions can be loaded with different certificates. I noticed playing with Java3D the other day that an unsigned application with a signed extension generates a dialog box that appears to be asking for permissions for the application rather than the extension - very different kettles of fish.

> This way, several extensions can be loaded with
> various security models.

Effectively, any loaded extension is trusted.

mthornton
Offline
Joined: 2003-06-10

Sandboxed code is allowed to communicate with the server on which it is hosted. This is reasonable for the main application as the user ought to know about it. However if there are a number of extensions hosted on other sites, then they are presumably allowed to communicate with their hosts too. Yet if they aren't signed and trusted, the user would not be notified about these extra places. As it is they will get the security dialog for each one.

Think about the possibilities for an "AdvertServer" extension ...

Perhaps untrusted extensions on different hosts should either be denied network connections altogether or only permitted to connect to the applications host.

alexter
Offline
Joined: 2006-11-10

Mark, this looks to me like a valid concern, unfortunately. On the other hand denying all the network connections (maybe except connections to the main app host) doesn't seem to kill a lot of useful extension possibilities. One more solution is showing a warning every time an untrusted extension tries to connect to its host; this would leave the possibility but let the extensions that don't require it run smoothly.
Anyway, looking forward to see Andy's judgement.
Alex

andyherrick
Offline
Joined: 2005-04-17

This is working fine for me in Java Web Start 1.5.0 and 6.0.
What version of Java Web Start are you using ?
I can reference the Sun extension for Java3D at:

from jnlp file hosted at any server.

/Andy

alexter
Offline
Joined: 2006-11-10

Thanks Andy!
I presume your app runs in the untrusted environment? This means I'm probably doing something wrong, which is not a big problem in contrast to WebStart not working well :).
I tried 1.5.0 and 1.6.0, but never mind - if it is supposed to work I'll find out what is wrong with my app.
Still, do you know, why component extensions are required to be trusted?

Thanks,
Alex

evickroy
Offline
Joined: 2004-07-23

Any chance that you could post the resources section of your JNLP file?

Erik

alexter
Offline
Joined: 2006-11-10

I'm sorry! Made noise out of nothing - I wasn't requesting all permissions in my component extension descriptor. Once I did, it started to work.
But still... My extension doesn't really need all the permissions. Why should I bother user with these security dialogs?
Thanks for your participation anyway!

Alex

alexter
Offline
Joined: 2006-11-10

Let me state it in a bit different way: why should component extension have any security settings at all? I thought it "runs" as a part of the application that references it and hence should inherit its environment.

Alex

andyherrick
Offline
Joined: 2005-04-17

Component extensions may or may not have the same security requirements as the main application or as another extension. In my simple Java 3D demo, the main program runs in the sandbox, but the Java 3D extension itself (at https://j3d-webstart.dev.java.net/release/java3d-latest.jnlp) needs all-permissions to load the native library for j3d.

For component extensions to be loaded from another downlaod host or protocol, the extension must be signed since the spec says:

5.7 Execution Environment for Component Extensions

All the JAR files specified in the resources elements for a component extension become part of the application's resources. JAR files for an extension must execute with the set of permissions specified in the extension descriptor, which is not necessarily the same set as the application.

By default, the component extension resources are executed in the untrusted execution environment. However, by using the security element, either of the trusted environments can be requested. Just as for an application, the resources must be signed and the user must trust the extension before it can be run in a trusted environment. An extension that contains native code will always need to request trusted access to the system.

---

and all resources of an untrusted application must be downloaded from the same host, since the spec says:

---

5.5 Untrusted Environment

All applications are by default run in an untrusted, or restricted environment, by a JNLP Client. The restricted environment is similar to the well-known Applet sandbox, and is designed so untrusted applications are prevented from intentionally or unintentionally harming the local system. For example, the restricted environment limits access to local disk and the network.

When run in the restricted execution environment, the following restrictions must be enforced on the application:

Single download host: All JAR files specified in the resources elements of the JNLP file must be downloaded from the same host, the download host.
----

/Andy

alexter
Offline
Joined: 2006-11-10

Andy,

Thanks for the detailed response! In fact, the specs says all that even more clearly in 5.5: [i]...Extensions requested from hosts other than the one that the JAR files were downloaded from must be signed and trusted ...[/i]
What I'm trying to understand is why it says so. If neither app nor extension require a trusted environment why can't they reside on different hosts? I have a feeling that the answer lies somewhere in the jungle of Java security and I won't be able to understand it anyway :).
Also, by any chance could you point to some resource that explains how the application and extension environments are separated? I have a very naive understanding of Java security mechanics and this understanding implies the following: if some party (widely recognized as trusted) develops an extension that [i]potentially[/i] can be triggered to harm the system, but intended for "peaceful" purposes (say an utility to work with files) a malicious application can trigger that extension to do harm without even requesting permissions for itself. This obviously must be false implication, but I really want to understand why it is false.

Sorry if I bother you with stupid or even senseless questions. Just want to gain a clear vision of the subject before I develop something that cannot work even in theory.

Alex

andyherrick
Offline
Joined: 2005-04-17

Since yesterdays post I too have been wondering why the restriction exists against unsigned extensions being downloaded from other hosts. I will revisit this for the next release of the spec, as it seems to me this would not be a security vunerability.

By signing and publically posting an extension, an organization is aserting that it could not be triggered in malicious ways. If a general purpose module is only non-malicious because of the way an application uses it, then it should be included directly in the application and the application signed, instead of releasing the module as an extension.

Withing the JNLPClassLoader, trust is granted to CodeSources based on combination of the request in the jnlp file containing that resource, and the users acceptance of the security dialog based on the CodeSigners in that CodeSource. (This is one reason all jars in a jnlp file must be signed by the same Certificates).
This way, several extensions can be loaded with various security models.

/Andy

alexter
Offline
Joined: 2006-11-10

Thanks a lot, Andy! Things look clear to me now. Based on your second paragraph all contradictions cease. However, the requirement to guarantee that your extension can't be triggered in a malicious way before you publish it seems too severe. Especially since there are only two trusted environments available, both allowing wide access to the system, one should do a deep security analysis of his component if he wishes to publish it as an extension :).
But at least it's clear.
Alex