Java problems on FC6/strict
Ted Rule
ejtr at layer3.co.uk
Thu Feb 1 18:46:36 UTC 2007
To begin at the beginning...
I was trying to configure my FC6 machine so that I could run the
OpenOffice SVG Import Filter here:
http://www.ipd.uka.de/~hauma/svg-import/
I also wanted to be able to run Java as a plugin to Firefox-2.0.0.1.
FFX2 runs Ok on FC6 - it just needs a few minor SELinux workrounds.
The big problem with the SVG Import Filter is that it requires Java 1.5,
so I've always assumed that the GNU Java 1.4.2 compatible RPMs won't
support some of the more esoteric Java API functions. Hence the
perceived need to install the latest Sun Java RPMs.
I previously had both Sun-Java/Firefox and OpenOffice/SVG-Import working
Ok on FC4 - again with a few minor policy patches.
So I duly installed Sun's jre-1.5.0_10 RPM, and for good measure I
manually adjusted the /etc/alternatives/java settings to make
/usr/bin/java point to Sun.
I also "execstack -l"'ed all the Sun Libraries so as to reduce the
propensity for it to need exectack/execmem/execmod permissions.
With all this in place, I ran up OpenOffice, going to Tools -> Options
-> Java in an attempt to select Sun Java as the prefered JVM.
Needless to say, avc's galore showed up in /var/log/messages.
After quite a while trying to tweak SELinux policy to suit, I gave up
the fight and decided that my next best option was to simply tweak file
labels and policy so that Java was executed in user_t rather than
user_javaplugin_t.
I therefore gave bin/java bin/java_vm and bin/javaws in Sun-jre
a "java_notrans_exec_t" label,
and added can_exec(user_t, java_notrans_exec_t)
The last hurdle was that Sun JRE is full of execstack/execmem/execmod
problems - still - so I had to enable the global allow_execmem boolean -
only.
With all of this in place, and with NO relabel of the GNU Java binaries
on the same box or any other policy changes to user_t permissions, I was
finally able to see Sun Java as a valid JVM from inside OpenOffice.
However, I noted that GNU Java was still throwing up lots of avc's when
I opened OpenOffice -> Tools -> Options -> Java
As an example of the avc's generated by staff_javaplugin_t trying to
open GNU Java from OpenOffice, I have this log snippet:
[root at topaz log]# grep gij messages| grep 14:26:47 | grep -v granted
Feb 1 14:26:47 topaz kernel: audit(1170340007.573:4914): avc: denied
{ write } for pid=6774 comm="gij" name="[32609]" dev=pipefs ino=32609
scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4915): avc: denied
{ write } for pid=6774 comm="gij" name="[32610]" dev=pipefs ino=32610
scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4916): avc: denied
{ read } for pid=6774 comm="gij" name="[32525]" dev=pipefs ino=32525
scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4917): avc: denied
{ write } for pid=6774 comm="gij" name="[32525]" dev=pipefs ino=32525
scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4918): avc: denied
{ read } for pid=6774 comm="gij" name="[32528]" dev=pipefs ino=32528
scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4919): avc: denied
{ write } for pid=6774 comm="gij" name="[32528]" dev=pipefs ino=32528
scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4920): avc: denied
{ read } for pid=6774 comm="gij" name="[32529]" dev=pipefs ino=32529
scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4921): avc: denied
{ write } for pid=6774 comm="gij" name="[32529]" dev=pipefs ino=32529
scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4922): avc: denied
{ read } for pid=6774 comm="gij" name="ooo680en-US.res" dev=hda6
ino=1760867 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4923): avc: denied
{ read } for pid=6774 comm="gij" name="ofa680en-US.res" dev=hda6
ino=1760866 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4924): avc: denied
{ read } for pid=6774 comm="gij" name="ooo680en-US.res" dev=hda6
ino=1760867 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4925): avc: denied
{ read } for pid=6774 comm="gij" name="sfx680en-US.res" dev=hda6
ino=1760876 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4926): avc: denied
{ read } for pid=6774 comm="gij" name="vcl680en-US.res" dev=hda6
ino=1760888 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4927): avc: denied
{ read } for pid=6774 comm="gij" name="sw680en-US.res" dev=hda6
ino=1760881 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4928): avc: denied
{ read } for pid=6774 comm="gij" name="svx680en-US.res" dev=hda6
ino=1760880 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4929): avc: denied
{ read } for pid=6774 comm="gij" name="svt680en-US.res" dev=hda6
ino=1760879 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4930): avc: denied
{ read write } for pid=6774 comm="gij" name="svdb.tmp" dev=hda5
ino=219746 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=staff_u:object_r:staff_tmp_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.826:4952): avc: denied
{ getattr } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6
ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.826:4953): avc: denied
{ getattr } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6
ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.827:4954): avc: denied
{ getattr } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6
ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.827:4955): avc: denied
{ read } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6
ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
Feb 1 14:26:47 topaz kernel: audit(1170340007.847:4960): avc: denied
{ execute } for pid=6783 comm="gij" name="addr2line" dev=hda6
ino=359825 scontext=staff_u:staff_r:staff_javaplugin_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
[root at topaz log]#
Running up Sun Java inside Firefox I came across a similar set of
problems, and was similarly forced to run Sun java in user_mozilla_t
instead of user_javaplugin_t to get it to work. I haven't bothered
to try and run GNU Java inside Firefox, as yet. As with user_t, I had to
grant user_mozilla_t execmem permissions because of the broken Sun
binaries.
The Java "test page" I was using in Firefox is here, FWIW:
http://www.java.com/en/download/help/testvm.xml
Meanwhile, for historical background:
Looking back at the FC4 policy, I seems that Java run from user_t
has no corresponding javaplugin_domain() definition in
base_user_macros.te and hence would always have run in user_t.
Meanwhile, on FC4, Java run from user_mozilla_t would run in
user_mozilla_javaplugin_t.
By contrast, FC6 seems to run java in user_javaplugin_t irrespective
of whether one starts from user_t or user_mozilla_t; this just seems a
bit odd to me.
To ease the problems associated with running Java from OpenOffice, could
I therefore request that an extra boolean be added to policy, namely
"disable_java_trans", which defaults OFF, and can be enabled to achieve
the same effect as my manual relabel for both user_t and user_mozilla_t
domains.
I would also like to try and disable the execmem boolean, but obviously
that requires a recompile of the entire Sun RPM from scratch. Does
anyone on this list know who we might approach at Sun so as to get them
to rebuild their JVM with a newer/cleaner compiler toolkit?
As with previous postings, I'm currently running
selinux-policy-strict-2.4.6-27
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
More information about the fedora-selinux-list
mailing list