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)
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
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):
Steps to Reproduce:
Notice that Fedora does not provide a Java applet plugin for epiphany,
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
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
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
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.