Bug 187484 - SELinux prevents xmame and xmess from running
SELinux prevents xmame and xmess from running
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Glide3 (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-31 04:53 EST by Andre Robatino
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: selinux-policy 2.2.34-3.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-28 05:26:42 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 Andre Robatino 2006-03-31 04:53:37 EST
Description of problem:
  The selinux updates of 3/29 prevent xmame and xmess from running:

[andre@localhost ~]$ xmame
xmame: error while loading shared libraries: /usr/lib/libglide3.so.3: cannot
restore segment prot after reloc: Permission denied
[andre@localhost ~]$ xmess
xmess: error while loading shared libraries: /usr/lib/libglide3.so.3: cannot
restore segment prot after reloc: Permission denied
[andre@localhost ~]$

Corresponding messages from dmesg:

audit(1143798901.453:368): avc:  denied  { execmod } for  pid=4985 comm="xmame"
name="libglide3-v2.so" dev=dm-0 ino=4184328
scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
audit(1143798903.297:369): avc:  denied  { execmod } for  pid=4986 comm="xmess"
name="libglide3-v2.so" dev=dm-0 ino=4184328
scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file

I don't understand SELinux at all, so I just picked a random SELinix package. 
Please reassign to the correct component.

Version-Release number of selected component (if applicable):
selinux-policy-2.2.25-2.fc5

How reproducible:
always

Steps to Reproduce:
1.  Try running xmame or xmess.
  
Actual results:
above error messages

Expected results:
should run without being blocked

Additional info:
I'm using the latest xmame and xmess from Freshrpms on an i386.
Comment 1 Daniel Walsh 2006-03-31 09:40:57 EST
You can fix this problem with a 

chcon -t textrel_shlib_t /usr/lib/libglide3.so.3

This rule is in the policy but the sort algorithm is broken.

But this should be reported as a bug against xmame/xmess whichever owns
libglide3.so.3 with this link.

http://people.redhat.com/drepper/selinux-mem.html
.
Comment 2 Daniel Walsh 2006-03-31 10:21:44 EST
BTW What does 
matchpathcon /usr/lib/libglide3.so.3

show?
Comment 3 Stephen Smalley 2006-03-31 10:59:26 EST
Policy looks sane here:

# rpm -q selinux-policy-targeted
selinux-policy-targeted-2.2.25-2.fc5

# /usr/sbin/matchpathcon /usr/lib/libglide3.so.3
/usr/lib/libglide3.so.3 system_u:object_r:textrel_shlib_t
Comment 4 Andre Robatino 2006-03-31 15:13:14 EST
[andre@localhost ~]$ rpm -qf /usr/lib/libglide3.so.3
Glide3-20050815-3.fc5

  This is in Fedora Extras.
Comment 5 Stephen Smalley 2006-03-31 15:32:25 EST
Ah, the light dawns.  /usr/lib/libglide3.so.3 is a symlink.
The real files are named /usr/lib/libglide-v[0-9]*\.so
Comment 6 Andre Robatino 2006-04-04 17:10:31 EDT
  So is this a Glide3 bug?  If so, I'll reassign to that package.  (The latest
SELinux updates made no difference, BTW.)
Comment 7 Andre Robatino 2006-04-11 20:02:49 EDT
  Problem still exists with today's updates (selinux-policy-2.2.29-3.fc5 et
al.).  Repeating the previous question, should I reassign this to Glide3?
Comment 8 Robert Morrison 2006-04-12 11:12:28 EDT
Today's selinux updates have broken xmame for me again.  To say that I find this
annoying is a large understatement.

The fix detailed by Daniel Walsh in comment #1 above does work.  It's not clear
to me why this would be regarded as a bug with xmame/xmess when it appears that
selinux is preventing an application from loading a library it needs.
Comment 9 Andre Robatino 2006-04-19 02:19:09 EDT
  Since I haven't gotten a response, I'm reassigning this bug to Glide3 in
Fedora Extras.
Comment 10 Daniel Walsh 2006-04-19 12:42:50 EDT
How have the updates broken xmame?  What avc messages are you seeing?

What does 
matchpathcon /usr/lib//usr/lib/libglide-v1.s0 show?

ls -lZ /usr/lib//usr/lib/libglide-*

http://people.redhat.com/~drepper/selinux-mem.html
Explains what the execmod problem is.
Comment 11 Andre Robatino 2006-04-19 12:52:28 EDT
  The avc messages are in comment #1.  The impression I get from the above
responses is that this bug is associated with the Glide3 package, since the
SELinux error is associated with a file in this package, but since I never got a
response to my question above, I had to just reassign the bug and see what
happens.  I think that xmame/xmess have been broken ever since FC5 came out. 
The later SELinux and xmame/xmess updates made no difference (Glide3 has not
been updated, though).

[andre@localhost ~]$ /usr/sbin/matchpathcon /usr/lib//usr/lib/libglide-v1.s0
/usr/lib//usr/lib/libglide-v1.s0        system_u:object_r:lib_t
[andre@localhost ~]$
Comment 12 Andre Robatino 2006-04-26 16:51:38 EDT
  With today's selinux-policy and selinux-policy-targeted updates
(2.2.34-3.fc5), xmame and xmess work again.  The following messages appeared
during "yum update":

/sbin/restorecon reset /usr/lib/libglide3-v3.so context
system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t
/sbin/restorecon reset /usr/lib/libglide3-v1.so context
system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t
/sbin/restorecon reset /usr/lib/libglide3-v2.so context
system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t
/sbin/restorecon reset /usr/lib/libglide3-v5.so context
system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t

so the SELinux policy apparently now doesn't block these files anymore.  I
should have left the bug assigned to the selinux-policy packages but I can't
reassign it now so am just closing the bug.
Comment 13 Ulrich Drepper 2006-04-26 17:00:10 EDT
I really don't like this tendency to add all kinds of exceptions to the policy
to allow broken programs to survive.  This only means that the real bugs will
never be fixed.  As exemplified by the fact that the category of the bug was
changed.

This is a bug in glide and nowhere else!

Fix that damn code.  100% of all critical bugs in RHEL4 are in desktop programs.
 We cannot be forgiving when it comes the policy affecting desktop apps.
Comment 14 Andre Robatino 2006-04-26 17:08:15 EDT
  Reopened since Glide3 is not fixed yet.  BTW, Sun's JRE also works again now
and there were similar exception messages involving the JRE files, so someone
needs to tell Sun to fix their code also if it hasn't been done already.
Comment 15 Hans de Goede 2006-04-27 13:56:41 EDT
I just got a mail that this bug got assigned to me, without any further
explanation. What fun, and how polite!

Can someone please explain to me what the problem exactly is? I know a bit about
SELinux but not everything there is to no. Currently on my mostly up2date
rawhide system I get:
-rwxr-xr-x  root     root     system_u:object_r:lib_t         
/usr/lib/libglide3-v1.so
-rwxr-xr-x  root     root     system_u:object_r:lib_t         
/usr/lib/libglide3-v2.so
-rwxr-xr-x  root     root     system_u:object_r:lib_t         
/usr/lib/libglide3-v3.so
-rwxr-xr-x  root     root     system_u:object_r:lib_t         
/usr/lib/libglide3-v5.so

Which would seem to mean that the exception has been removed as Ulrich
requested. So that makes for one happy Ulrich and one unhappy me.

Since I'm both the current maintainer of the xmame/xmess Glide code and the
maintainer of Glide3 in extras one would have thought I would have been bitten
by this, but I haven't. Appereantly this problem is only present when the
libglide3.so.3.10 symlink points to libglide3-v1.so. (Yes I have SELinux with
the targeted policy enabled).

Can someone explain to me why a lib would need textrel_shlib_t instead of just
plain lib_t and what I can do to fix this? Thanks!
Comment 16 Ulrich Drepper 2006-04-27 15:39:26 EDT
Text relocations are the result of using position dependent code in a DSO or
PIE.  See http://people.redhat.com/drepper/dsohowto.pdf for explanations of
building DSOs.

You can hopefully easily determine what is wrong by building the binaries with
debug info and then use the eu-findtextrel utility from elfutils.  It should
point you to the files which either are not compiled with -fpic/-fPIC or which
contain assembler code which is position dependent.
Comment 17 Hans de Goede 2006-04-27 15:49:12 EDT
I'll take a look, but I'm afraid this is probably in some piece of assembler
code and although I'm not afraid at all of touching C-code my asm knowledge is
very bad.

It has taken me a conciderable amount of time to get Glide3 into any sort of
shape at all (I fixed a zillion strict antialiasing warnings amongst other
things), and I'm afraid this one is going to be beyond my capabilities.

Rescently some applications have shown up in extras which use the following
method to work nicely with SELinux:
http://fedoraproject.org/wiki/Packaging/SELinux#head-39d41d058c94d09a077ef6e2623b16b9369d87d1

Would this be an acceptable solution? I know _really_ fixing things would be
better, but concidering the small amount of people still using / needing Glide3
and the needed effort from my side I would prefer to leave things as is and just
fix the SELinux-labels.

(The above sortoff assumes that the problem is not just a missing -fPIC, in
 that case I'll just fix things).
Comment 18 Hans de Goede 2006-04-27 18:48:13 EDT
As I already feared this is in the hanf written / profiled timing optimized
triangeldraw asm code, of which their are mmx 3dnow and sse versions for 4
different Voodoo chipsets, that is a lott of asm!

So I'm going to modify the Glide3 packages to fixup the libglide.so SELinux type
itself as described under:
http://fedoraproject.org/wiki/Packaging/SELinux#head-39d41d058c94d09a077ef6e2623b16b9369d87d1

Will this work for FC-4, FC-5 and devel? Is this nescesarry for FC-4 ?
Comment 19 Hans de Goede 2006-04-28 05:26:42 EDT
I've added the folowing to the specfile, to set to context to textrel_shlib_t
on i386 (where the asm gets used).

%ifarch %{ix86}
Requires(post):   policycoreutils /sbin/ldconfig
Requires(postun): policycoreutils /sbin/ldconfig
%endif

%ifarch %{ix86}
%post
/sbin/ldconfig   
# Set SELinux file_context in the policy
semanage fcontext -a -t textrel_shlib_t '%{_libdir}/libglide3-v.\.so' 2>/dev/nu
# Actually change the context
chcon -t textrel_shlib_t %{_libdir}/libglide3-v?.so || :
%else
%post -p /sbin/ldconfig
%endif

%ifarch %{ix86}
%postun
/sbin/ldconfig
# SELinux support
if [ $1 -eq 0 ]; then  # final removal
  semanage fcontext -d -t textrel_shlib_t '%{_libdir}/libglide3-v.\.so' 2>/dev/
fi
%else 
%postun -p /sbin/ldconfig 
%endif

I've tested this on FC-5 i386 and devel x86_64 and it works as expected. This
has been comitted to CVS and builds have beenr equested for devel and FC-5.
Comment 20 Daniel Walsh 2006-05-01 16:13:12 EDT
The latest policyupdate should have these marked as textrel_shlib_t so this is
not necessary.  Fixing the library is what we need.  Until the policy will use
textrel_shlib_t.

Dan
Comment 21 Hans de Goede 2006-05-01 16:27:20 EDT
Erm,

I already build this update and it has already been pushed to the mirrors. If
I'm not mistaken then these scriplets can't harm even with a policy which
doesn't require them anymore, correct? In that case I'm going to leave things as
is since I don't want tp ush a needless update.

Also I don't plan on fixing the libs, they are really Legacy and although I plan
on fixing any real bugs and keep them working with the latest dev chain I'm not
planning on doing any additional work.

Last note, the textrel_shlib_t is only needed on i386, hence I've made the
scriplets conditional on the arch in the spec, did you do the same for the policy?

You might concider removing this exception from the policy (assuming the
scriptlets work as advertised) since I see little reason for an exception in
_the_ policy for a package very few users will install.

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