Bug 127537 - [RFI] Inclusion of gcjwebplugin or other Open Source Java applet plugin
[RFI] Inclusion of gcjwebplugin or other Open Source Java applet plugin
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
:
Depends On: 127534 187869
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2004-07-09 11:24 EDT by W. Michael Petullo
Modified: 2007-11-30 17:10 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-25 11:36:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description W. Michael Petullo 2004-07-09 11:24:30 EDT
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:
Comment 1 Bill Nottingham 2004-07-12 16:58:49 EDT
Well, if it's running inside a mozilla process, it would use whatever
security policy mozilla has.
Comment 2 Thomas Fitzsimmons 2004-07-12 17:07:08 EDT
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?
Comment 3 W. Michael Petullo 2004-07-12 17:16:22 EDT
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.
Comment 4 Doncho N. Gunchev 2004-11-11 19:50:34 EST
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)
Comment 5 W. Michael Petullo 2005-04-08 11:56:41 EDT
What about Kaffe?  Does their appletviewer implement the appropriate security
restrictions?  Could it be turned into a browser plugin?
Comment 6 Anthony Green 2005-04-11 20:34:35 EDT
(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.
Comment 7 Anthony Green 2005-04-11 20:37:50 EDT
(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.

Comment 8 Warren Togami 2005-06-01 06:08:15 EDT
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.
Comment 9 Bill Nottingham 2005-10-04 16:51:29 EDT
Assigning towards the java team - please reassign to the appropriate engineer as
necessary.
Comment 10 Anthony Green 2006-07-18 00:39:52 EDT
This is going to happen for FC6, right?
Comment 11 Thomas Fitzsimmons 2006-07-18 17:11:13 EDT
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.
Comment 12 Warren Togami 2006-07-18 21:12:33 EDT
Note that you must go through the Core Package Review process too.
Comment 13 Thomas Fitzsimmons 2006-07-18 21:41:04 EDT
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?
Comment 14 Thomas Fitzsimmons 2006-07-25 11:36:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.