Bug 516057 - gets whacked by selinux execmem check
gets whacked by selinux execmem check
Product: Fedora
Classification: Fedora
Component: webkitgtk (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Extras Quality Assurance
: Reopened, Triaged
: 512139 522917 524806 524852 525131 525583 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-08-06 10:55 EDT by Bill Nottingham
Modified: 2014-03-16 23:19 EDT (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-16 18:01:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
backtrace (12.75 KB, text/plain)
2009-09-24 10:22 EDT, Jiri Koten
no flags Details

  None (edit)
Description Bill Nottingham 2009-08-06 10:55:56 EDT
Description of problem:

Clicking on any entry causes liferea to crash, as SELinux kills it:

type=SYSCALL msg=audit(1249570217.761:557): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=4000 a2=7 a3=22 items=0 ppid=10605 pid=10606 auid=2166 uid=2166 gid=2167 euid=2166 suid=2166 fsuid=2166 egid=2167 sgid=2167 fsgid=2167 tty=pts2 ses=42 comm="liferea" exe="/usr/bin/liferea" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1249570217.761:557): avc:  denied  { execmem } for  pid=10606 comm="liferea" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process

Sure enough, there's:

10606 mmap(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EACCES (Permission denied)

in the strace.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Start liferea
2. Click somewhere
Comment 2 Bill Nottingham 2009-08-06 11:16:53 EDT
This is webkit's JS interpreter, ExecutableAllocator.
Comment 4 Peter Gordon 2009-08-08 17:11:07 EDT
Thanks for the bug report!

I think I've traced this to the ENABLE_ASSEMBLER_WX_EXCLUSIVE macro setting in the JS interpreter (as you mentioned, Bill), and am running a mock build now to test it. T
Comment 5 Bill Nottingham 2009-08-10 11:48:31 EDT
Note that the latest rawhide policy is more lenient about execmem/execstack, and may allow this to work. But that's only a temporary solution.
Comment 6 Peter Gordon 2009-08-23 20:57:38 EDT
I believe this to be fixed as of webkitgtk-1.1.12-2.fc12, which was just built
into rawhide yesterday. However as I don't have a rawhide installation available, cCould you please test and verify whether or not the included no-execmem patch was successful in resolving this?

Thanks very much.
Comment 7 Tomasz Torcz 2009-08-24 02:23:19 EDT
I'm not the original reported, but it work OK for me now.
Comment 8 Bill Nottingham 2009-09-21 12:20:22 EDT
This is back in rawhide with:

Comment 9 Bill Nottingham 2009-09-21 12:20:48 EDT
*** Bug 522917 has been marked as a duplicate of this bug. ***
Comment 10 Alexey Torkhov 2009-09-22 09:57:00 EDT
*** Bug 524852 has been marked as a duplicate of this bug. ***
Comment 11 Christoph Wickert 2009-09-24 10:14:58 EDT
*** Bug 525131 has been marked as a duplicate of this bug. ***
Comment 12 Jiri Koten 2009-09-24 10:21:07 EDT
midori segfaults with Selinux enabled

Version-Release number of selected component:
Comment 13 Jiri Koten 2009-09-24 10:22:42 EDT
Created attachment 362503 [details]

Comment 14 Adam Williamson 2009-09-24 10:32:50 EDT
Setting this as blocking final release as it could have unpredictable and wide-ranging effects (lots of stuff uses WebKit to render Web content these days, and we don't want all those apps falling over apparently at random).

Fedora Bugzappers volunteer triage team
Comment 15 Peter Gordon 2009-09-24 15:28:09 EDT
I thought that this had been fixed with the no-execmem patch. Seems not. :(

Unfortunately, it wasn't until recently (when I acquired my lovely T500) that I could move my desktop to Rawhide. I'll look into this further first then when I home from class this evening. :)

Comment 16 Peter Gordon 2009-09-25 11:03:12 EDT
*** Bug 525583 has been marked as a duplicate of this bug. ***
Comment 17 Peter Gordon 2009-09-25 11:17:13 EDT
I've built into rawhide this morning, which disables the JIT. It's a temporary hack, but does workaround this bug until I can delve into the code more deeply and figure out why it's still using executable memory even with ENABLE_ASSEMBLER_WX_EXCLUSIVE defined from the patch.
Comment 18 Adam Williamson 2009-09-25 11:45:41 EDT
is it a good enough 'temporary hack' that we can ship the beta with it if necessary?

Fedora Bugzappers volunteer triage team
Comment 19 Mathieu Bridon 2009-09-25 15:08:05 EDT
I confirm that webkit built with JIT disabled makes the following apps stop crashing wit this SELinux denial:
- liferea (this bug)
- empathy (bug 525583)
- epiphany (possibly bug 510931)
Comment 20 Oliver Hunt 2009-09-26 03:12:46 EDT
What is the restriction that selinux is failing from?  Does it not allow switching to and from writable and executable memory?
Comment 21 Peter Gordon 2009-09-26 12:41:30 EDT
@Adam: Yes, this at least makes WebKit function properly. The only downside is a bit of a performance hit on JavaScript-heavy pages since the JIT compilation is disabled. But, I've been using this over the past couple of days with Epiphany and Midori without issue. If it comes down to it, this should be an okay EVR for the beta.

@Oliver: According to the description from Ulrich Drepper (http://people.redhat.com/drepper/selinux-mem.html), the restriction is that somewhere in the JIT compiler, memory is either being mapped anonymous and executable (with mmap and PROT_EXEC), or is mapping a file a file with MAP_PRIVATE and both PROT_EXEC and PROT_WRITE. 

Admittedly I've not looked into it any deeply yet, and am not sure where this bug occurs (or which of these it its) within the JIT code.

Comment 22 Oliver Hunt 2009-09-26 15:22:02 EDT
> @Oliver: According to the description from Ulrich Drepper
> (http://people.redhat.com/drepper/selinux-mem.html), the restriction is that
> somewhere in the JIT compiler, memory is either being mapped anonymous and
> executable (with mmap and PROT_EXEC), or is mapping a file a file with
> Admittedly I've not looked into it any deeply yet, and am not sure where this
> bug occurs (or which of these it its) within the JIT code.
> Thanks.  

I was wanting to know what memory access restrictions SELinux is enforcing -- i work on the JSC JIT so know what JSC is doing :D
Comment 23 Ian Weller 2009-10-17 20:59:42 EDT
*** Bug 512139 has been marked as a duplicate of this bug. ***
Comment 24 Oliver Hunt 2009-10-18 14:51:58 EDT
Is anyone going to answer my question?
Comment 25 Bill Nottingham 2009-10-19 12:40:36 EDT
I'm not sure how the answer in #21 isn't clear -- it's one of those two, and the code in question should make it fairly obvious which.
Comment 26 Adam Williamson 2009-10-23 12:42:02 EDT
This bug was discussed at the blocker bug review meeting today. As per #512845, execmem checks are disabled in final release, so execmem problems do not need to block the release. it's still a valid bug, though.

Fedora Bugzappers volunteer triage team
Comment 27 Bug Zapper 2009-11-16 06:16:21 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
Comment 28 Benjamin Otte 2010-07-13 07:29:52 EDT
For anybody l(In reply to comment #3)
> http://people.redhat.com/drepper/selinux-mem.html
> http://gcc.gnu.org/viewcvs/trunk/libffi/src/closures.c?revision=150042&view=markup
> for examples of fixes.    

For anyone looking at this code: The top URL has changed to http://www.akkadia.org/drepper/selinux-mem.html
Comment 29 Kevin Fenzi 2010-09-11 13:53:23 EDT
I built a webgkitgtk here with JIT re-enabled and with Peters patch for f14. 


I think the performance increase is pretty big. 
(sunspider: ~1200 without JIT, ~350 with. Firefox4 gets ~600 here(smaller is better))

I am also not seeing any execmem denials with the above build on my f14 machine. 
Can other folks give a look and see?

I don't know that it's worth looking at changing in f12/f13 at this point, but I would really like to fix rawhide and f14 if possible.
Comment 30 Kevin Fenzi 2010-09-11 13:56:23 EDT
*** Bug 524806 has been marked as a duplicate of this bug. ***
Comment 31 Kevin Fenzi 2010-09-11 14:30:59 EDT
Sorry for additional spam, forgot to cc myself here. ;(
Comment 32 Kevin Fenzi 2010-09-24 11:52:52 EDT
Well, I went ahead and pushed this into rawhide's 1.3.4 version. ;) 

Please feel free to re-open this or file a new bug if you see it occuring again there... 
I'll probibly also update f14 at some point before release too if possible.
Comment 33 Christoph Trassl 2010-11-28 14:43:07 EST
Since Fedora 14 webkitgtk segfaults when all selinux allow_exec* booleans are set to off.

I have a machine where all these allow_exec* booleans are turned off and i cannot use devhelp and midori any longer (since upgrading to Fedora 14).

Some might say, that i even cannot use firefox if the booleans are set this way, but at least in Firefox you can turn off jit in preferences.

Rebuilding webkitgtk-1.3.6-1.fc14 with --disable-jit fixes the segfaults in devhelp and midori (and presumably all other software that depends on webkitgtk).

Is it possible to package two versions of webkitgtk, one with --disable-jit and one normal?
Comment 34 Kevin Fenzi 2010-11-28 14:45:39 EST
Uh. I do not see any segaults or issues here with selinux. I use midori full time. 

perhaps you are seeing bug: 648319 ?
Comment 35 Christoph Trassl 2010-11-28 15:06:13 EST
I was pretty sure, that my problem is related to this bug, did not seem like 648319 at first. Now i am not sure any more, since it webkit applications started crashing with webkitgtk-1.3.4.

I will provide a kickstart file to reproduce my problem, then we'll see.
Comment 36 Christoph Trassl 2010-11-29 14:47:48 EST
Unfortunately i had not the time to provide a kickstart file by now, but i can confirm the behaviour i described in comment 33 on a pretty untouched Fedora 14 i686 desktop installation. The problems are the same on x86_64.

If allow_execstack == 0: devhelp, midori will at startup crash

If allow_execstack == 1: devhelp, midori work fine

The following snippets are ltrace/strace snippets with allow_execstack=0:

$ ltrace midori
<... webkit_web_view_new resumed> )                                                = 0x8cab028
webkit_web_view_get_type(0x2aad7b, 0x53827c, 0xbfa32678, 0x48a5da, 0x8b3e858)      = 0x8d18770
g_type_check_instance_cast(0x8cab028, 0x8d18770, 0xbfa32678, 0x48a5da, 0x8b3e858)  = 0x8cab028
webkit_web_view_open(0x8cab028, 0x80bea9b, 0xbfa32678, 0x48a5da, 0x8b3e858 <unfinished ...>
g_str_hash(0x8da1c20, 0xdba44c, 5, 0xda9000, 0x432af0)                             = 49
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

$ strace midori
gettimeofday({1290999203, 862043}, NULL) = 0
mmap2(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EACCES (Permission denied)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

Perhaps this helps to point me to the right bug/people to get this resolved.
Comment 37 Kevin Fenzi 2010-11-29 14:58:08 EST
I don't see this here. ;( 

Try a 'fixfiles onboot' reboot and see if the problem persists?
Comment 38 Christoph Trassl 2010-12-01 12:38:06 EST
fixfiles onboot did not resolve the problem.

But i realized that midori seems not a good example for my problems with webkitgtk since f14. Depending on the user a browser has plugins enabled which crash when not allowed execstack, execmem, so my problem with midori is esoteric and not a common use case.

But devhelp is a very good example. I have an old box here, Pentium 4/3.40, i686. I installed Fedora i386 DVD (Use All Space, Enable Installation repo, Enable Fedora - i386 repo, Enable Fedora - i386 updates repo (not testing)). Only customization is: Add package group "Gnome Software Development".

After reboot, login, check for any outstanding updates:

1. devhelp runs without crashes

2. setsebool allow_execmem=0

3. devhelp crashes with "Segmentation fault (core dumped)"

And i am sure this worked in f13.
And i know that compiling webkitgtk with --disable-jit helps.

Version information: webkitgtk-1.3.6-1.fc14, devhelp-2.32.0-1.fc14
Comment 39 Kevin Fenzi 2010-12-05 13:33:19 EST
ok. I had some time to dig around some more this weekend... 

this bug seems to be 32bit specific, which explains why I never saw it. (I only have one small netbook thats still 32bit). 

So, now that I can duplicate it, will see if I can find a fix, or be forced to disable jit. ;( 

allow_execmem is not default right?
Comment 40 Oliver Hunt 2010-12-05 15:32:11 EST
What is the stack trace of the failure? eg. is it during a call to mmap or writing to memory later?

I'm still not sure i fully understand the SELinux restrictions -- does it disallow flipping memory between writable and executable, so requiring two pages being mapped, one writable one executable? or does it simply disallow memory to be writable and executable at the same time?

If the latter then simply switching ENABLE_ASSEMBLER_WX_EXCLUSIVE to 1 in Platform.h (or as a define leading into the build) should be sufficient to have everything work correctly.  If it's crashing at that point due a W/X violation then it would be really good to know what the stacktrace is as it may point to new code that isn't ensuring correct permissions prior to writing.

If selinux disallows a given page to ever alternate between writable and executable then that will need support coded into JSC, in which case a bug will need to be filed at bugs.webkit.org, and realistically someone who works with SELinux will probably need to do the work (as we won't be able to test).  We will of course be happy to help anyone who wants to work on that though.
Comment 41 Kevin Fenzi 2010-12-05 15:39:02 EST
I've been trying to get a trace off my little netbook, but abrt has been spinning for a long time. ;( 

If someone could duplicate this on a 32bit box and attach the trace here (or point to an abrt bug where it's filed) that would be great. ;)
Comment 42 Kevin Fenzi 2010-12-11 17:02:14 EST
I still can't seem to get my little netbook to spit out a trace. ;( 
Anyone else able to do so for me?

Also, 1.3.7 is out (it has some issues where it's not building/installing translations so I have not made any update for it). You can try a scratch build at: 

Comment 43 Kevin Fenzi 2010-12-22 02:06:20 EST
1.3.8 is out: 

testing welcome.
Comment 44 Fedora Admin XMLRPC Client 2011-03-15 13:19:09 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 45 Fedora End Of Life 2012-08-16 18:01:20 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

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