Red Hat Bugzilla – Bug 127537
[RFI] Inclusion of gcjwebplugin or other Open Source Java applet plugin
Last modified: 2007-11-30 17:10:45 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Description of problem: I would like to see gcjwebplugin (http://www.nongnu.org/gcjwebplugin/) or another Open Source Java applet plugin included in Fedora. Thomas Fitzsimmons said the following in an email to the fedora-devel mailing list: Unfortunately, we can't ship gcjwebplugin and gcjappletviewer with Fedora Core 3 in their current form because they haven't been audited for security. However, I'm wondering if there is some way of using existing security infrastructure to limit gcjappletviewer's capabilities. That way we could at least ship a feature-limited version so that people could experiment with trusted applets. I'd like to see something I could start testing. Perhaps an SELinux could be written to ensure gcjwebplugin is restricted for testing purposes? Or maybe packages could be started and hosted by someone on people.redhat.com along with proper disclaimers? Or would fedora.us be a better place? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Notice that Fedora does not provide a Java applet plugin for epiphany, mozilla, etc. Additional info:
Well, if it's running inside a mozilla process, it would use whatever security policy mozilla has.
gcjwebplugin spawns an applet viewer, gcjappletviewer, as a separate process. gcjappletviewer loads and runs the applet's bytecode, and displays itself in the plugin window using the XEMBED protocol. Does this mean there is still hope for defining a capability-limiting SELinux policy?
If gcjwebplugin forks a seperate process then SELinux could be used to restrict this new process more than mozilla. It would be a neat test of SELinux's capabilities to see if it could properly enforce a Java "sandbox." This would reduce the amount of code gcjwebplugin would require. Of course, gcjwebplugin would have to refuse to run if SELinux was not enforcing a proper security policy.
Why "gcjwebplugin would have to refuse to run if SELinux was not enforcing a proper security policy"? Won't this prevent users from running without SELinux or in permisive mode? (I don't say it's a good idea, I just think it should be possible)
What about Kaffe? Does their appletviewer implement the appropriate security restrictions? Could it be turned into a browser plugin?
(In reply to comment #5) > What about Kaffe? Does their appletviewer implement the appropriate security > restrictions? Could it be turned into a browser plugin? No. There's no reason to trust Kaffe any more than libgcj. We're all merging our runtime libraries with GNU Classpath, so virtually all Free runtimes will be in the same boat.
(In reply to comment #4) > Why "gcjwebplugin would have to refuse to run if SELinux was not > enforcing a proper security policy"? Won't this prevent users from > running without SELinux or in permisive mode? Yes, that's right. I don't think we should depend on SELinux in order to run.
We shouldn't depend on SELinux for security either. SELinux is not the "first and only" line of defense for anything else in the distribution. This being said, now that we have FC4, nothing prevents us from building gcjwebplugin into Extras where it belongs for now. Due to the insecurity however, I would recommend making the plugin NOT install into a browser plugin directory by default. The user needs to run a setup script and type "yes" after reading the security warning. Then it sets up the plugin symlinks in browser dirs. I have code that does exactly this, so let me know when the Extras package is ready, and I'll setup the package.
Assigning towards the java team - please reassign to the appropriate engineer as necessary.
This is going to happen for FC6, right?
It depends if Bryce gets the backport in before the FC6test2 freeze. And the backport depends on his libgcj-bc.so work; I'm not sure if that's done yet. As soon as the backport is in, I'll build my java-1.4.2-gcj-compat-plugin patch into Rawhide.
Note that you must go through the Core Package Review process too.
libgcjwebplugin.so will be included in libgcj.rpm, and java-1.4.2-gcj-compat-plugin will be a new sub-package of java-1.4.2-gcj-compat. Do new sub-packages need to go through the Fedora Core Package Review Process?
gcc-4.1.1-12, which contains libgcjwebplugin.so, went into Rawhide last night, along with java-1.4.2-gcj-compat-plugin which installs an alternatives-managed "libjavaplugin.so" symlink in /usr/lib/mozilla/plugins. Rawhide users who would like to test the plugin can run: yum install java-1.4.2-gcj-compat-plugin then re-start Firefox. Browse to about:plugins to confirm that the plugin is installed and recognized by the browser. For each applet you attempt to load, before even starting to load it, gcjwebplugin displays a cautionary dialog box about the state of GNU Classpath's security implementation. The dialog allows you to either not load the applet or to trust the applet and load it. The GNU Classpath AWT and Swing code was in a state of flux when the backport that included gcjwebplugin was done (because of a large Java2D rewrite to make the Cairo backend the default), so there may be regressions in AWT and Swing applications for FC6test2. However, another GNU Classpath -> Fedora Core libgcj GUI backport is planned post FC6test2, which will fix most of these regressions. Please test java-1.4.2-gcj-compat-plugin and file bugs.