Red Hat Bugzilla – Bug 195821
programs built with ghc require SELinux allow_execmem=1 privilege to run
Last modified: 2007-11-30 17:11:35 EST
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
Version-Release number of selected component (if applicable):
whatever ghc version was used to compile the darcs-1.0.7-1.fc5 package in
Steps to Reproduce:
1. Run "darcs get --partial http://fasodjf.xyz/ajdlfk/"
darcs: internal error: getMBlock: mmap: Permission denied
Please report this as a compiler bug. See:
Invalid repository: http://fasodjkjf.xyz/ajdlfk
darcs failed: Failed to download URL http://fasodjkjf.xyz/ajdlfk/_darcs/invento
libcurl: couldn't resolve host
The upstream ticket is at http://cvs.haskell.org/trac/ghc/ticket/738
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.
I tried ghc-22.214.171.12460619-x86_64-unknown-linux and the problem still occurs
Apparently the above patch only handles execheap not execmem.
Dan, could some policy be added to selinux-policy to take care of this?
*** Bug 195820 has been marked as a duplicate of this bug. ***
chcon -t uncofined_execmem_exec_t EXECUTABLE
should allow it execmem without having to set allow_execmem.
But the app should really be fixed.
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.
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.
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. :-)
Adding unconfined_execmem_exec_t context to programs that use ghc rts
I cannot quite see the connection between the exec_mem problem and the
read/write access to three log files mentioned in comment #12.
(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... :)
Yes wrong bug. Removing by making it private.