Description of problem: According to the Mozilla Documentation Center (https://developer.mozilla.org/en/Java_in_Firefox_Extensions), the Java Firefox Extension by SIMILE (http://simile.mit.edu/wiki/Java_Firefox_Extension) established a technique for calling Java from within a Firefox extension. Even if Fedora 10 supports LiveConnect, the extension doesn't work as expected. Version-Release number of selected component (if applicable): 1.6.0.0-9.b14.fc10 How reproducible: You have just to download the sources, build them (via Ant) and install the Firefox Extension. Steps to Reproduce: 1. checkout the Subversion repository $ svn checkout http://simile.mit.edu/repository/java-firefox-extension/ java-firefox-extension 2. enter the working copy $ cd java-firefox-extension 3. edit the file firefox/install.rdf to increment the max version of the target application (Firefox). At line 32, replace <em:maxVersion>3.0</em:maxVersion> with <em:maxVersion>3.0.*</em:maxVersion> 4. build the sources $ ant 5. install the extension: drag the file java-firefox-extension-2.0.0.xpi and drop it on the Firefox window. Actual results: At every successive startup, the extension prompts an error message saying "java.lang.SecurityException: Changing the SecurityManager is not allowed.: Changing the SecurityManager is not allowed" Expected results: Under the Tools menu there should be an entry named "Java Firefox Extension: Do it!". If the user clicks on it, he should get a dialog box displaying 43. Subsequent invocations increment that number. Additional info: I suppose that there is an issue with the security manager (or the security policy), which doesn't allow the extension to execute the statement java.security.Policy.setPolicy(policy); located at line 97 in firefox/chrome/content/scripts/browser-overlay.js The following post describes a similar problem occurred with the Sun Microsystem VM: http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=fcdcd5d9fe8384f0fb6082c9dbba?bug_id=6745455
*** Bug 498108 has been marked as a duplicate of this bug. ***
This problem cannot be fixed with the current plugin design. The IcedTea plugin uses a single vm for all applet instances. The extension is trying to set a policy that will affect all future applets loaded in that instance, which is being rightfully denied. Does the extension work for you with the new Sun plugin? I get an IllegalArgumentException when it try..
Created attachment 341813 [details] Patch to SIMILE extension to fix IllegalArgumentException
> Does the extension work for you with the new Sun plugin? I get an > IllegalArgumentException when it try.. I uploaded a patch which fixes this problem: it is due to the fact that an expression like java.net.URL isn't anymore a reference to the Java Class; instead, you could create a dummy instance and invoke getClass() on it. > The extension is trying to set a > policy that will affect all future applets loaded in that instance, which is > being rightfully denied. Your notice is really important: I "hope" that the SUN plugin would restrict the effect of this statement to the classes loaded within the script, otherwise it will introduce a big security hole.
Closing bug. We cannot fix this.
>> The extension is trying to set a >> policy that will affect all future applets loaded in that instance, which is >> being rightfully denied. > > Your notice is really important: I "hope" that the SUN plugin would restrict > the effect of this statement to the classes loaded within the script, otherwise > it will introduce a big security hole. I am not an expert in Java Security, but it seems to me that the extension is trying to grant AllPrivileges only to classes in the code base expressed though the method addUrl of the custom policy. Am I wrong?
Hi, If this cannot be fixed then the IceTea plug-in design is broken (against JNLP specs see here details: http://jcp.org/aboutJava/communityprocess/mrel/jsr056/index3.html see section "5.6 Trusted Environments" specifically "The application must be run with a SecurityManager installed" and notice the "MUST" description , current IceTea plug-in violates this MUST. ) as no jnlp application requiring full privilege may be run. This is against the JNLP promise to support extended privilege after user confirmed trust of the application. I think these kind of bugs shall remain open until they are fixed as they are violating specification. see also https://bugzilla.redhat.com/show_bug.cgi?id=498108 Please reconsider leaving this open until fixed or leave 498108 open until fixed if you consider it is not duplicate of this bug. I will consider reopening the original 498108 as I cannot change this. Andrei.
(In reply to comment #6) ... > > I am not an expert in Java Security, but it seems to me that the extension is > trying to grant AllPrivileges only to classes in the code base expressed though > the method addUrl of the custom policy. Am I wrong? Correct. The extension is attempting to set a policy that defines additional permissions (java.security.AllPermissions) to URLs. (In reply to comment #7) > Hi, > > If this cannot be fixed then the IceTea plug-in design is broken (against JNLP > specs see here details: > http://jcp.org/aboutJava/communityprocess/mrel/jsr056/index3.html see section ... All applications are run with a SecurityManager installed. The issue is that the plugin is restricting changing of the security policy which will affect future applets. The correct fix is to switch to a per instance model, which may still not fix the issue. With a per instance vm, the extension may set a new policy, but there is no guarantee that the future instances will use the vm instance in which the new policy was set. What I am confused about is why is this extension trying to set the policy at all? Since you cannot guarantee which vm will load future code, changing policy would be futile. The extension itself (and any code IT loads) will always have full java permissions as mentioned in the specifications. This is easily verifiable by putting code like java.io.File...createNewFile() in one of the methods in the Test class. I tried it and it worked..
> What I am confused about is why is this extension trying to set the policy at > all? Since you cannot guarantee which vm will load future code, changing policy > would be futile. The extension itself (and any code IT loads) will always have > full java permissions as mentioned in the specifications. This is easily > verifiable by putting code like java.io.File...createNewFile() in one of the > methods in the Test class. I tried it and it worked.. I am not the author of the extension, thus I can only argue what it is doing... I am involved in a project, which uses this idiom to bootstrap a Jetty server, which in turn serves the requests form the GUI (via Ajax) and needs to access to the local file system (the class Test is responsible of initializing the server) The chrome code (i.e. JavaScript code within XUL files) is executed with higher privileges, thus it is supposed that also Java code is privileged. Java Update 12 fixes a bug, which caused the chrome JavaScript to be unprivileged http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=fcdcd5d9fe8384f0fb6082c9dbba?bug_id=6745455 According to the specification of the "New Java Plugin" the privileges aren't granted anymore on a per-call basis: http://java.sun.com/javase/6/webnotes/6u10/plugin2/liveconnect/index.html#SECURITY_MODEL Even if JavaScript code is privileged, I am not sure that classes loaded through URLClassLoader are privileged too. I haven't found any information about the security model of IcedTea: can I assume that the Java code called within the extension is privileged? In that case I could not use the Policy at all.
(In reply to comment #9) > The chrome code (i.e. JavaScript code within XUL files) is executed with higher > privileges, thus it is supposed that also Java code is privileged. > Can you tell me (or point me to) how to use this extension to bootstrap the jetty server? I looked around for docs on the site, but documentation is sparse. I'd be happy to test out the scenario... > Java Update 12 fixes a bug, which caused the chrome JavaScript to be > unprivileged > > http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=fcdcd5d9fe8384f0fb6082c9dbba?bug_id=6745455 > > According to the specification of the "New Java Plugin" the privileges aren't > granted anymore on a per-call basis: > > http://java.sun.com/javase/6/webnotes/6u10/plugin2/liveconnect/index.html#SECURITY_MODEL > The IcedTeaPlugin checks permissions on each call (this is how it is expected to be with the OJI API, which was used by the old Sun plugin and is currently used by IcedTea)[1]. The source of the call shouldn't matter if it is chrome://, as mozilla would tell java about the privileges to use anyway (in case of chrome, it would say 'provide all permissions'). > Even if JavaScript code is privileged, I am not sure that classes loaded > through URLClassLoader are privileged too. > > I haven't found any information about the security model of IcedTea: can I > assume that the Java code called within the extension is privileged? In that > case I could not use the Policy at all. Since IcedTea uses OJI, its security model significantly depends on Mozilla code as well. OJI defines certain methods that are security sensitive - like getting of variables, setting of variables, execution of methods (including constructors), etc. When a js tries to do any one of these actions, Mozilla communicates this to the plugin, which in turn passes the relevant data (variable name, method name, etc.) plus the source location of the script, plus security "privileges". Then, before execution, Java checks the security privileges. If Mozilla conveyed that AllPermissions are to be granted, Java continues on. If there is no indication from Mozilla as to the privileges, Java then checks it's policy as set by the plugin during initialization, and sees if the calling source is allowed to do whatever it is trying to do. If it is not, it is denied permission and the call fails, else it passes through. [1]: http://java.sun.com/j2se/1.3/docs/guide/plugin/security.html
> Can you tell me (or point me to) how to use this extension to bootstrap the > jetty server? I looked around for docs on the site, but documentation is > sparse. I'd be happy to test out the scenario... I was working on a Semantic Bookmarking and Ontology Development tool [1] based deployed as a Firefox extension. > The IcedTeaPlugin checks permissions on each call (this is how it is expected > to be with the OJI API, which was used by the old Sun plugin and is currently > used by IcedTea)[1]. The source of the call shouldn't matter if it is > chrome://, as mozilla would tell java about the privileges to use anyway (in > case of chrome, it would say 'provide all permissions'). If I understand well, there isn't any need of granting addition privileges, since they are already granted. Thus I could avoid to set the policy and execute directly the Java code. Is the policy still necessary in the new Java Plugin? I could modify the script like that: 1) try to load a class which needs elevated permissions (i.e. accessed to the local file system) 2) if the operation succeeds, I can run the Jetty server 3) otherwise, I try to set the policy [1]: http://semanticturkey.uniroma2.it/
(In reply to comment #11) > > If I understand well, there isn't any need of granting addition privileges, > since they are already granted. Thus I could avoid to set the policy and > execute directly the Java code. > > Is the policy still necessary in the new Java Plugin? > Correct. The code is already running with full privileges, and JavaScript from the extension should be able to load and run Jetty without the need to set policy. > I could modify the script like that: > 1) try to load a class which needs elevated permissions (i.e. accessed to the > local file system) > 2) if the operation succeeds, I can run the Jetty server > 3) otherwise, I try to set the policy > Yes, that seems like the right way. During the course of investigating this, I did find one point where the extention was failing (even after disabling setPolicy()). I have put up a patch for review upstream [1], once it is there, the next Fedora update (coming soon) will have that fix. [1]: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-April/005471.html
> Yes, that seems like the right way. During the course of investigating this, I > did find one point where the extention was failing (even after disabling > setPolicy()). I have put up a patch for review upstream [1], once it is there, > the next Fedora update (coming soon) will have that fix. Is this patch solving the jnlp problem? ( see duplicate : 498108 )
No, the patch does not fix that. I have reopened 498108, as I believe trusted webstart applications SHOULD have the authority to replace the SM as per the specifications. It is only for the plugin that it should not be allowed IMO.
(In reply to comment #12) I have applied your patch to the latest source package of openjdk (15.b14.fc10) and installed the modified binaries on my system. Also, I have modified the Java Firefox Extension, so that if the setPolicy fails, then it avoid to use the policy again. However, the script raises an exception of type "java.lang.reflect.InvocationTargetException", when it tries to invoke the static method "newInstance" of the class "TracingClassLoader". I have attached a patch, which should be applied to the sources provided by the author. Can you reproduce the error? Does IcedTea have a Java Console similar to that provided by the SUN Java plugin? And how can I open it?
Created attachment 342238 [details] Don't use the Policy
I don't think it's going to be possible to get away without setting a policy here. URLClassLoader will, by default, grant loaded classes the ability to read the file they were loaded from, and that's it. While one could create a custom ClassLoader without this restriction, there's no way to load it without a URLClassLoader which would drop privileges, so there's a bit of a Catch-22. Unless I'm mistaken, until the underlying issue here gets fixed, you can access built-in Java classes from JavaScript with full privileges, but you can't assign full privileges to classes you load yourself.
Never say never. I've managed to get this working. The code is in our SVN tree at https://www.zotero.org/svn/integration/xpcom/OpenOffice/trunk/components/zoteroOpenOfficeIntegration.js https://www.zotero.org/svn/integration/xpcom/OpenOffice/trunk/build/src/org/zotero/integration/ooo/PrivilegedURLClassLoader.java The PrivilegedURLClassLoader inherits from URLClassLoader, but provides full permissions to its child classes. We load this class manually out of our JAR file from JavaScript, using the protected defineClass method of a URLClassLoader object (so that we can load it as privileged). We create an instance, and then we use this to load the rest of our JAR files. It's an ugly hack, especially given the messiness of LiveConnect, but it works.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.