would someone please fix the problem with firefox and thunderbird not starting when using the latest strict policy(selinux-policy-strict-1.27.1-11)? Below are the AVC messages from audit.log when trying to start them Thanks, Richard Hally
type=AVC msg=audit(1128231114.093:32): avc: denied { execmod } for pid=2731 comm="firefox-bin" name="libxpcom_core.so" dev=dm-0 ino=3965047 scontext=richard:staff_r:staff_mozilla_t:s0-s0:c0.c127 tcontext=system_u:object_r:shlib_t:s0 tclass=file type=SYSCALL msg=audit(1128231114.093:32): arch=40000003 syscall=125 success=no exit=-13 a0=e9c000 a1=e0000 a2=5 a3=bfd2a710 items=0 pid=2731 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="firefox-bin" exe="/usr/lib/firefox-1.5/firefox-bin" type=AVC_PATH msg=audit(1128231114.093:32): path="/usr/lib/firefox-1.5/libxpcom_core.so" ----------------------------------------------------------- type=AVC msg=audit(1128231322.472:40): avc: denied { execmod } for pid=2869 comm="thunderbird-bin" name="libxpcom_core.so" dev=dm-0 ino=3701297 scontext=richard:staff_r:staff_thunderbird_t:s0-s0:c0.c127 tcontext=system_u:object_r:shlib_t:s0 tclass=file type=SYSCALL msg=audit(1128231322.472:40): arch=40000003 syscall=125 success=no exit=-13 a0=739000 a1=e0000 a2=5 a3=bfe1ebc0 items=0 pid=2869 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="thunderbird-bin" exe="/usr/lib/thunderbird-1.5/thunderbird-bin" type=AVC_PATH msg=audit(1128231322.472:40): path="/usr/lib/thunderbird-1.5/libxpcom_core.so"
Richard Hally wrote:
would someone please fix the problem with firefox and thunderbird not starting when using the latest strict policy(selinux-policy-strict-1.27.1-11)? Below are the AVC messages from audit.log when trying to start them
Hi Richard, the problem is easily worked around by marking the following libraries texrel_shlib_t, as they contain Text Relocations. However, I think a better goal would be to eliminate those text relocations where possible, along with the rest of the libraries marked in distros.fc.
Steven, can you clarify what needs to be done to get fix those applications... I am currently not very clear on what the problem is, since I'm not familiar with the linking process.
/usr/lib/firefox-1.5/libgfxpsshar.so /usr/lib/firefox-1.5/libgkgfx.so /usr/lib/firefox-1.5/libxpcom_compat.so /usr/lib/firefox-1.5/libgtkembedmoz.so /usr/lib/firefox-1.5/libxpcom_core.so /usr/lib/firefox-1.5/libgtkxtbin.so /usr/lib/firefox-1.5/libxpcom.so /usr/lib/firefox-1.5/libjsj.so /usr/lib/firefox-1.5/libsoftokn3.so /usr/lib/firefox-1.5/libxpistub.so
On Sun, 2005-10-02 at 03:19 -0400, Ivan Gyurdiev wrote:
Hi Richard, the problem is easily worked around by marking the following libraries texrel_shlib_t, as they contain Text Relocations. However, I think a better goal would be to eliminate those text relocations where possible, along with the rest of the libraries marked in distros.fc.
Steven, can you clarify what needs to be done to get fix those applications... I am currently not very clear on what the problem is, since I'm not familiar with the linking process.
/usr/lib/firefox-1.5/libgfxpsshar.so /usr/lib/firefox-1.5/libgkgfx.so /usr/lib/firefox-1.5/libxpcom_compat.so /usr/lib/firefox-1.5/libgtkembedmoz.so /usr/lib/firefox-1.5/libxpcom_core.so /usr/lib/firefox-1.5/libgtkxtbin.so /usr/lib/firefox-1.5/libxpcom.so /usr/lib/firefox-1.5/libjsj.so /usr/lib/firefox-1.5/libsoftokn3.so /usr/lib/firefox-1.5/libxpistub.so
I think that one would have to go look at the actual code and build process for those objects to determine why they are being marked as requiring textrel and what needs to be done to fix them. Were they built with -fpic? Do they include hand-written assembly? Ulrich, is there a FAQ anywhere already to which we can refer people to help them track down the cause of text relocations and fix them (not just working around them in policy)?
On Sun, 2005-10-02 at 01:46 -0400, Richard Hally wrote:
would someone please fix the problem with firefox and thunderbird not starting when using the latest strict policy(selinux-policy-strict-1.27.1-11)? Below are the AVC messages from audit.log when trying to start them
You should always bugzilla such issues so that they can be tracked properly...
Stephen Smalley wrote:
On Sun, 2005-10-02 at 01:46 -0400, Richard Hally wrote:
would someone please fix the problem with firefox and thunderbird not starting when using the latest strict policy(selinux-policy-strict-1.27.1-11)? Below are the AVC messages from audit.log when trying to start them
You should always bugzilla such issues so that they can be tracked properly...
Perhaps someone who understands the problem and possibly the solution and which package to file against could help us out here?
BTW, the other part of the problem is possibly related to the "devel's mcs breaks prelink and FC4 compat" thread. When I do 'touch /.autorelabel' and reboot, Firefox and Thunderbird will start. If I then do another reboot without the autorelabel they will then not start.
Just speculating here but it seems that something is being kept in memory from relabeling that allows these apps to start but is not there when doing an ordinary boot. But that is just speculation. Is it FF and T'bird or is it SELinux?
Also, this problem has been occurring with Firefox for several months but has only started occurring with T'bird in the last week or so. These are the only two apps I have tried on my strict/MCS test box.
Richard Hally
On Mon, 2005-10-03 at 23:16 -0400, Richard Hally wrote:
Perhaps someone who understands the problem and possibly the solution and which package to file against could help us out here?
I'd file it against firefox, as that owns the .so files that are triggering these denials. Someone needs to look at the build process and code for those .so files to determine why they presently require text relocations and how to fix them.
Just speculating here but it seems that something is being kept in memory from relabeling that allows these apps to start but is not there when doing an ordinary boot. But that is just speculation. Is it FF and T'bird or is it SELinux?
Hmm...well, SELinux should trigger an execmod denial on shlib_t always, regardless of the MCS level. Labeling them with texrel_shlib_t should make it go away, but it would be better to fix the files to not require text relocations.
It is possible for the incore inode security label to become inconsistent with the on-disk xattr (example: access a file with a given type to bring its inode incore and map its xattr to an incore label, then remove the type from the policy and reload it, at which point the incore label will be remapped to the unlabeled_t type, and remain that way until the inode is evicted from memory even if a subsequent policy reload re-adds the type). The patch queued up for 2.6.15 that will allow SELinux to canonicalize getxattr results will ensure that a getxattr/getfilecon will always return the actual incore inode security label to userspace.
Stephen Smalley wrote:
On Mon, 2005-10-03 at 23:16 -0400, Richard Hally wrote:
Perhaps someone who understands the problem and possibly the solution and which package to file against could help us out here?
I'd file it against firefox, as that owns the .so files that are triggering these denials. Someone needs to look at the build process and code for those .so files to determine why they presently require text relocations and how to fix them.
Perhaps it would be appropriate to reevaluate the implementation strategy for this particular "feature" of SELinux.
If there is no coherent, concise, convincing explanation provided to the people who need to make changes to their software to conform to the requirements of this "feature" then there isn't much hope of them doing what is required. Since this "feature" was implemented many months ago and these problems are still appearing please consider filing bugs with the appropriate explanation so that the appropriate people can make the required changes.
Thanks, Richard Hally
On Tue, 2005-10-04 at 17:04 -0400, Richard Hally wrote:
Perhaps it would be appropriate to reevaluate the implementation strategy for this particular "feature" of SELinux.
If there is no coherent, concise, convincing explanation provided to the people who need to make changes to their software to conform to the requirements of this "feature" then there isn't much hope of them doing what is required. Since this "feature" was implemented many months ago and these problems are still appearing please consider filing bugs with the appropriate explanation so that the appropriate people can make the required changes.
Hi,
I think all you need to do is file a bugzilla against firefox and report what you reported originally, and note that these .so's have text relocations. Then it is up to the maintainer for that package (and ultimately the upstream developers) to address the issue. The notion that text relocations are bad isn't something novel to SELinux by any means. We simply added controls to SELinux over the resulting attempt to modify the memory protections at the suggestion of the Red Hat developers so that this can be controlled by policy.
You can also bugzilla policy if you like so that the permissions can be added in the short term until the package is fixed.
This is no different than any other bug you might encounter in a particular package; when you find the bug, file it against the package. The policy can certainly workaround it in the short term, but that doesn't improve security; it just permits the status quo.
selinux@lists.fedoraproject.org