If you enable and enforce the targeted policy in Debian and you use darcs you need to allow it to use execmem:
chcon -t unconfined_execmem_exec_t /usr/bin/darcs
This allows to overcome these denials:
type=AVC msg=audit(1191957463.678:108): avc: denied { execmem } for pid=14811 comm="darcs" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process
And get this ugly message:
$ darcs w -l
darcs: internal error: getMBlock: mmap: Permission denied
(GHC version 6.6.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
Since oolite complained of the same issue I also ran this:
chcon -t unconfined_execmem_exec_t /usr/lib/GNUstep/System/Applications/oolite.app/oolite
Update: If you want to know the reasons why darcs (a VCS) to need execmem read the RedHat bugs related to this and the upstream bug report on GHC: https://bugzilla.redhat.com/show_bug.cgi?id=195820
https://bugzilla.redhat.com/show_bug.cgi?id=195821
http://cvs.haskell.org/trac/ghc/ticket/738
4 comments:
How come a VCS need execmem ?
It is written in Haskell and the compiler generates such code that is needed. See the upstream bug report and Ulrich Drepper's explanation on execmem.
EddyP
The Drepper's explanation of execmem includes example that creates a temporary file (in /home instead of /dev/shm!) and maps it twice, once for writing and once for execution. Now despite it unlinks the file again before even mapping, I would not be sure it's a good solution security-wise.
Now despite it unlinks the file again before even mapping, I would not be sure it's a good solution security-wise.
Why? What makes it insecure? Explain a scenario where this is insecure.
EddyP
Post a Comment