Tuesday 9 October 2007

selinux darcs policy; same for oolite

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:

Anonymous said...

How come a VCS need execmem ?

Anonymous said...

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

Anonymous said...

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.

Anonymous said...

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