Bug 201648 - Seamonkey does not start with selinux set to enforced
Seamonkey does not start with selinux set to enforced
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: seamonkey (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kai Engert (:kaie) (on vacation)
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-07 18:09 EDT by Gérard Milmeister
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-15 13:05:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
contains errors related to seamonkey failure (4.46 MB, text/plain)
2006-08-14 17:31 EDT, Jim Cornette
no flags Details

  None (edit)
Description Gérard Milmeister 2006-08-07 18:09:50 EDT
The shared libraries cause an "avc: execmod" event from
selinux. Either the .so files must be set to textrel_shlib_t
using local policy, or a request filed to selinux to update
the standard policies.
Comment 1 jlbartos 2006-08-09 09:15:03 EDT
I am seeing the exact same thing and strace confirms.
Comment 2 jlbartos 2006-08-09 09:17:09 EDT
Forgot to add: seamonkey-1.0.4-0.5.1.fc5
Comment 3 Jim Cornette 2006-08-14 06:53:41 EDT
Adding myself to the list. I am having to set SELinux to permissive in order for
seamonkey to load.
Comment 4 Jim Cornette 2006-08-14 17:31:27 EDT
Created attachment 134170 [details]
contains errors related to seamonkey failure

This problem has been noted by several users and other users have been
installing the installer version instead of using the rpm version since it does
not start. Other people just see it not starting. A lot of users are impacted
by this problem.
Comment 5 Kai Engert (:kaie) (on vacation) 2006-08-15 13:05:57 EDT
So after some research, I am able to explain what is going on.

In the first place I had suspected a change in the application code, because
Seamonkey 1.0.2 starts fine in enforcing mode - the 1.0.4 rpm code does not.

But why does Firefox work? I suspected a difference at the source level.

But comparing the source we compile for Firefox 1.5.0.6 and Seamonkey 1.0.4
shows, there are only minimal unrelated differences.

Researching more, I learned that shared libraries in both packages have the same
behaviour with regards to selinux. But only the Seamonkey libraries trigger the
exception. This confused me.

Finally I learned that Firefox (and Thunderbird) work, because the
selinux-policy does explicitly allow the libraries in those applications to do
"execmod". I was not aware of that exception!

Obviously somebody has already made the decision that fixing the Mozilla code is
too difficult and opted for the exception in the policy.

Therefore I propose to file a bug about the selinux policy in order to add the
same exception for the Seamonkey application, as it is in place for Firefox and
Thunderbird.

I will file such a bug next.
I'm closing this as NOTABUG, because there is no bug in Seamonkey.

I am left with the question, why the .so files in our Seamonkey 1.0.2 package do
not have that execmod requirement. And it seems, binaries produced by
mozilla.org do not either. I guess the cause is the use of a different
compilation environment.
Comment 6 Jim Cornette 2006-08-15 18:46:38 EDT
I have mozilla-1.7.13-1.1.fc5 installed also. Mozilla seems to work with SELinux
in enforcing. Why seamonkey-1.0.4-0.5.1.fc5 does not work is beyond what I could
thing of.
ls -lZ shows that the below files have particular content. I know how to disable
SELinux or put it into permissive mode. I do not know how to make the content
match for the desired rules. I notice that mozilla does not have a version of
this .so file. The errors in my audit log flag this .so file more than any other
message in the log.

Thanks for your investigation.

 locate libxpcom_core.so
/usr/lib/firefox-1.5.0.6/libxpcom_core.so
/usr/lib/seamonkey-1.0.4/libxpcom_core.so
/usr/lib/thunderbird-1.5.0.5/libxpcom_core.so
[root@dell-cornette ~]# ls -lZ /usr/lib/firefox-1.5.0.6/libxpcom_core.so
-rwxr-xr-x  root root system_u:object_r:textrel_shlib_t
/usr/lib/firefox-1.5.0.6/libxpcom_core.so
[root@dell-cornette ~]# ls -lZ /usr/lib/seamonkey-1.0.4/libxpcom_core.so
-rwxr-xr-x  root root system_u:object_r:lib_t         
/usr/lib/seamonkey-1.0.4/libxpcom_core.so
[root@dell-cornette ~]# ls -lZ /usr/lib/thunderbird-1.5.0.5/libxpcom_core.so
-rwxr-xr-x  root root system_u:object_r:textrel_shlib_t
/usr/lib/thunderbird-1.5.0.5/libxpcom_core.so
Comment 7 Kai Engert (:kaie) (on vacation) 2006-08-15 18:57:27 EDT
> Therefore I propose to file a bug about the selinux policy in order to add the
> same exception for the Seamonkey application, as it is in place for Firefox and
> Thunderbird.
> 
> I will file such a bug next.

Bug 202642
Comment 8 Kai Engert (:kaie) (on vacation) 2006-08-15 19:14:42 EDT
Jim, until bug 202642 gets fixed, a workaround is to explicitly allow textrel
for seamonkey .so files:

(use at your own risk)

root> find /usr/lib/seamonkey-1.0.4/ -name \*.so | xargs chcon -t texrel_shlib_t
Comment 9 Jim Cornette 2006-08-15 22:06:15 EDT
Thanks for the use at my own risk information posted in comment #8. It may be
risky, but it does allow seamonkey to function and selinux protection for the
other system factors. I'll track bug 202642 for progress.

There was discussion on the fedora-list regarding this effect on seamonkey rpms.
A link to the start of the thread is listed below.

https://www.redhat.com/archives/fedora-list/2006-August/msg01448.html

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