Bug 190181

Summary: exec_mod denial FAQ is not permanent
Product: [Fedora] Fedora Documentation Reporter: Chad Sellers <csellers>
Component: selinux-faqAssignee: Chad Sellers <csellers>
Status: CLOSED CURRENTRELEASE QA Contact: Karsten Wade <kwade>
Severity: medium Docs Contact:
Priority: medium    
Version: develCC: kwade
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://fedora.redhat.com/docs/selinux-faq/
Whiteboard:
Fixed In Version: 1.5.6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-28 22:07:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Chad Sellers 2006-04-28 15:25:45 UTC
exec_mod denial FAQ changes context of the library, but does not make this
permanent across relabels. To do this, we need to use semanage to set the file
context in the store. The FAQ should reflect this.

Additionally, this should show both the execmod denial as well as the potential
error which a user might see on the command line, like:
error while loading shared libraries: /usr/lib/libavutil.so.49: cannot restore
segment prot after reloc: Permission denied

Original message:
On Fri, 2006-04-28 at 02:11 -0700, Andrew Morton wrote:
> g'day.
> 
> - Latest FC5
> 
> - Get into freshrpms.net by installing
>  
http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/5/freshrpms-release/freshrpms-release-1.1-1.fc.noarch.rpm
> 
> - yum install kino
> 
> Now running kino gives:
> 
> kino: error while loading shared libraries: /usr/lib/libavutil.so.49: cannot
restore segment prot after reloc: Permission denied
> 
> Did
> 
> sony:/home/akpm# echo 0 > /selinux/enforce        
> sony:/home/akpm# 
> 
> and voila.
> 
> Who do I blame?

Blame the library, and file a bug against it noting that it requires a
text relocation and asking them to fix it.  The following information
may help them understand, drawn from a comment by Ulrich Drepper in a
similar bugzilla against another library:

"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."

To allow it to proceed in the meantime while staying enforcing, you can
do:
# /usr/sbin/semanage fcontext -a -t textrel_shlib_t '/usr/lib/libavutil.so.[0-9]*'
# /sbin/restorecon -v /usr/lib/libavutil.so.49

This tells SELinux to label the file with a type that indicates that it
requires text relocation and then applies that label to it.
Subsequently relabels or rpm installs/updates should then preserve it
since you added it to your local file contexts via semanage.  Later you
can remove it with semanage fcontext -d if the library is fixed
upstream.

Chad, Dan - can this be added to the Fedora SELinux FAQ?  I see that the
FC5 SELinux FAQ does mention the use of chcon -t textrel_shlib_t, but
that won't survive a relabel or package update, right?  And it really
needs to be in terms of the error the user will actually see (i.e. the
cannot restore segment prot after reloc message), not the SELinux denial
that they might not see unless they know to look in /var/log/messages or
audit.log (depending on whether they are running auditd).

By the way, you can also refer them to bug 187484 at bugzilla.redhat.com
for reference, as that includes similar discussion for Glide and
includes helpful hints like what they ended up adding to the specfile so
that the package itself sets the type appropriately.  But it would be
preferable to eliminate the need for the text relocation, as it has both
overhead and security implications (the latter is the ability to execute
potentially arbitrary code due to executing from a modified private file
mapping).

-- 
Stephen Smalley

FAQ version:  selinux-faq-1.5.5 (2006-04-07)

Comment 1 Chad Sellers 2006-04-28 17:30:24 UTC
Addressed in cvs