Bug 195821
| Summary: | programs built with ghc require SELinux allow_execmem=1 privilege to run | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Hans Ulrich Niedermann <rhbugs> |
| Component: | ghc | Assignee: | Jens Petersen <petersen> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | drepper, dwalsh, extras-qa |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | FC6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-01-21 22:36:38 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 195820 | ||
|
Description
Hans Ulrich Niedermann
2006-06-18 08:19:59 UTC
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-6.4.2.20060619-x86_64-unknown-linux and the problem still occurs with it. 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. *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. :-) Adding unconfined_execmem_exec_t context to programs that use ghc rts in ghc-6.4.2-3.fc6. 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. |