Bug 195821 - programs built with ghc require SELinux allow_execmem=1 privilege to run
programs built with ghc require SELinux allow_execmem=1 privilege to run
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ghc (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 195820
  Show dependency treegraph
 
Reported: 2006-06-18 04:19 EDT by Hans Ulrich Niedermann
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: FC6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-21 17:36:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans Ulrich Niedermann 2006-06-18 04:19:59 EDT
Description of problem:

  Software written using ghc requires SELinux allow_execmem=true priviledge.

  I ran into this when running darcs (see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195820), but I am sure
someone with Haskell knowledge can construct a much simpler test case exposing
the problem.

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

  whatever ghc version was used to compile the darcs-1.0.7-1.fc5 package in
Fedora Extras

How reproducible:

  Every time.

Steps to Reproduce:
  
  1. Run "darcs get --partial http://fasodjf.xyz/ajdlfk/"
  
Actual results:

  darcs: internal error: getMBlock: mmap: Permission denied
      Please report this as a compiler bug.  See:
      http://www.haskell.org/ghc/reportabug

Expected results:

  Invalid repository:  http://fasodjkjf.xyz/ajdlfk

  darcs failed:  Failed to download URL http://fasodjkjf.xyz/ajdlfk/_darcs/invento
ry
  libcurl: couldn't resolve host

Additional info:
Comment 1 Hans Ulrich Niedermann 2006-06-21 05:22:09 EDT
The upstream ticket is at http://cvs.haskell.org/trac/ghc/ticket/738
Comment 2 Hans Ulrich Niedermann 2006-06-21 10:28:07 EDT
The ghc darcs changelog has an entry from 2006-05-30 which is supposed to fix
the problem. I haven't tested any recent snapshots of ghc-6.4.2 (which will
become ghc-6.4.3) or ported that patch to back to ghc-6.4.2 yet, though.
Comment 4 Jens Petersen 2006-06-22 00:52:17 EDT
I tried ghc-6.4.2.20060619-x86_64-unknown-linux and the problem still occurs
with it.
Comment 5 Jens Petersen 2006-06-22 09:45:35 EDT
Apparently the above patch only handles execheap not execmem.

Dan, could some policy be added to selinux-policy to take care of this?
Comment 6 Jens Petersen 2006-06-22 09:48:23 EDT
*** Bug 195820 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Walsh 2006-06-22 10:52:48 EDT
chcon -t uncofined_execmem_exec_t EXECUTABLE 

should allow it execmem without having to set allow_execmem.

But the app should really be fixed.
Comment 8 Jens Petersen 2006-06-23 00:08:42 EDT
Upstream added support for execheap (above patch), but for execmem they object to
having to go to such lengths to work around such a restrictive security policy.
"GHC really does do runtime code generation, so it really does need some
writable/executable memory."  So they hope some policy can be added
for ghc and programs using its RTS.

Anyway setting  "chcon -t unconfined_execmem_exec_t" in %post works for darcs
at least, thanks.
Comment 9 Hans Ulrich Niedermann 2006-06-23 05:18:41 EDT
Is this really just "working around such a restrictive security policy"?

One could argue that making the writable/executable memory thing as secure as
humanly possibly is just plain common sense, even if that requires writing code
in one address and executing it in another. Alas, requiring execmem priviledges
indicates that the code is not as secure as humanly possible.

After looking at the code example
(<URL:http://people.redhat.com/drepper/selinux-mem.html>) I think an
implementation of that is possible, and the fact that this will improve all
software written in Haskell makes it even more desirable.
Comment 10 Hans Ulrich Niedermann 2006-06-24 06:40:23 EDT
*cough*

After having had a look at ghc/rts/MBlock.c I don't think this can be trivially
ported, at least not with my average C app programmer level knowledge.

I won't have the time soon to climb the learning curve required (mmap alignment,
C heap, ...), so if there are any other takers, feel welcome to have a go at it. :-)
Comment 11 Jens Petersen 2006-09-25 06:04:21 EDT
Adding unconfined_execmem_exec_t context to programs that use ghc rts
in ghc-6.4.2-3.fc6.
Comment 13 Hans Ulrich Niedermann 2006-09-29 19:42:07 EDT
I cannot quite see the connection between the exec_mem problem and the
read/write access to three log files mentioned in comment #12.
Comment 14 Jens Petersen 2006-09-29 23:21:13 EDT
(In reply to comment #13)
> I cannot quite see the connection between the exec_mem problem and the
> read/write access to three log files mentioned in comment #12.

I assume they were paste to the wrong bug... :)
Comment 15 Daniel Walsh 2006-10-02 14:25:54 EDT
Yes wrong bug.  Removing by making it private.

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