Bug 3975

Summary:	executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode
Product:	Fedora	Reporter:	Isaac Hailperin <isaac.hailperin>
Component:	x264	Assignee:	Dominik 'Rathann' Mierzejewski <dominik>
Status:	RESOLVED FIXED
Severity:	normal	CC:	isaac.hailperin, kwizart, sergio
Priority:	P5
Version:	26
Hardware:	armhfp
OS:	GNU/Linux
namespace:

Description Isaac Hailperin 2016-02-15 21:35:22 CET

Overview: 
---------
In a system using selinux in enforcing mode, programs like mpd cannot use
libx264.so.148, as it has the executable stack flag set. However, this flag seems not
to be needed, as clearing the flag does not render the library disfunctional.
This is on an arm system, not sure if that is special in this regard.

Steps to Reproduce: 
-------------------
1) On a fedora 23 arm system, install mpd from fusion repo. This pulls in
libx264, among others.

2) Set selinux in enforcing mode and try to start mpd. It will fail,
complaining about being denied access:
/usr/bin/mpd: error while loading shared libraries: libx264.so.148: cannot enable executable stack as shared object requires: Permission denied

3) Set selinux in permissive mode and try to start mpd. It will succeed.

4) Execute "execstack -c /usr/lib/libx264*" and set selinux in enforcing
mode. Try to start mpd, this time it will succeed.

Expected Results: 
-----------------
mpd should be able to load libraries in selinux enforcing mode without
modifications of the library nessessary.

According to
http://danwalsh.livejournal.com/6117.html?thread=23525
the execstack flag should not be set.
Note this issues seems to be identical to https://bugzilla.rpmfusion.org/show_bug.cgi?id=3974 - though thats a different package.

Comment 1 Sérgio Basto 2016-02-15 22:39:27 CET

2 questions: 
You always talk in arm , and in x86 ? 
what is the solution ?

Personally I always disable selinux before begin anything

Comment 2 Isaac Hailperin 2016-02-16 14:27:33 CET

> You always talk in arm , and in x86 ? 
On x86_64, the problem seems not to be present:
$ execstack -q /usr/lib64/libx264.so.148 
- /usr/lib64/libx264.so.148

I have no x86 32 bit system, so I can't tell.

|
> what is the solution ?
The man page for execstack (http://linux.die.net/man/8/execstack) suggests that this is something that can be influenced at build time, so I guess there must be some way to build this into the spec file. 
The fedora packaging wiki mentions using the execstack utility during the build process:
https://fedoraproject.org/wiki/Packaging_tricks#Executable_stack


> Personally I always disable selinux before begin anything
:) While this seems to be a common practice, I don't consider this to be a solution. The execstack flag is considered a security issue in itself (which is why its not allowed by default in fedora), so even without selinux, it shouldn't be there.

Comment 3 Dominik 'Rathann' Mierzejewski 2016-07-19 02:27:17 CEST

I'll take a look at this. Could you try running execstack -c on the installed library in the meantime?

Comment 4 Sérgio Basto 2016-07-19 02:35:19 CEST

(In reply to comment #3)
> I'll take a look at this. Could you try running execstack -c on the installed
> library in the meantime?

Be my guest , in  meantime I read your thread on packaging Mailing list about sse3 , I'd like understand if we need 2 builds for i686 ... one with sse2 other without it, can you give us your opinion ? 

Thanks.

Comment 5 Isaac Hailperin 2016-07-20 21:18:35 CEST

(In reply to comment #3)
> I'll take a look at this. Could you try running execstack -c on the installed
> library in the meantime?

I did this (please see my original bug report, under "steps to reproduce", step 4), it is the workaround I am using.
However, should there ever be an update, this would have to be done again. So building a package with the flag cleared would be my preferred solution :)

Comment 6 Dominik 'Rathann' Mierzejewski 2016-08-26 19:38:18 CEST

(In reply to comment #5)
> (In reply to comment #3)
> > I'll take a look at this. Could you try running execstack -c on the installed
> > library in the meantime?
> 
> I did this (please see my original bug report, under "steps to reproduce", step
> 4), it is the workaround I am using.
> However, should there ever be an update, this would have to be done again. So
> building a package with the flag cleared would be my preferred solution :)

Right, you did. Sorry. I'm taking a closer look at the package. The issue seems to be limited to armv7 only (out of the three primary arches) and is reproducible in rawhide as well.

Comment 7 Dominik 'Rathann' Mierzejewski 2016-08-28 01:22:14 CEST

This is fixed in x264-0.148-11.20160614gita5e06b9 built for F24+. If you still need this fixed for F23, please reopen and we'll backport.

Comment 8 Isaac Hailperin 2016-08-28 20:17:43 CEST

I am still on f23, but should upgrade soon, so for me the fix for f24 is sufficient. Thank you very much for looking into this and fixing it!