Bug 1290432 - PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction
PCRE-JITted code should be executed from non-writable memory to obey execmem ...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcre (Show other bugs)
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Petr Pisar
BaseOS QE - Apps
Vladimír Slávik
: FutureFeature
Depends On:
Blocks: 1298243 1420851
  Show dependency treegraph
Reported: 2015-12-10 08:55 EST by Petr Lautrbach
Modified: 2017-11-02 07:01 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
Performance of regular expressions cannot be boosted with the JIT technique if executable stack is disabled When the *SELinux* policy disallows executable stack, the *PCRE* library cannot use JIT compilation to speed up regular expressions. As a result, attempting JIT compilation for regular expressions is ignored and their performance is not boosted. To work around this problem, amend the *SELinux* policy with a rule for enabling the "execmem" action on affected *SELinux* domains to enable JIT compilation. Some of the rules are already provided and can be enabled by specific SELinux booleans. To list these booleans, see the output of the following command: getsebool -a | grep execmem An alternative workaround is changing application code to not request JIT compilation with calls to the *pcre_study()* function.
Story Points: ---
Clone Of: 1290205
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Petr Lautrbach 2015-12-10 08:55:48 EST
+++ This bug was initially created as a clone of Bug #1290205 +++

Description of problem:

When rear is being executed, e.g. /usr/sbin/rear mkrescue an SELinux AVC is generated. 

type=AVC msg=audit(1448377615.693:35710): avc:  denied  { execmem } for  pid=21398 comm="grep" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process

type=SYSCALL msg=audit(1448377615.693:35710): arch=x86_64 syscall=mmap success=no exit=EACCES a0=0 a1=10000 a2=7 a3=22 items=0 ppid=9928 pid=21398 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm=grep exe=/usr/bin/grep subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

SELinux is preventing /usr/bin/grep from using the execmem access on a process. The root cause seems to be the usage of "grep -P".

The problem is in sljit/sljitExecAllocator.c:

 97 static SLJIT_INLINE void* alloc_chunk(sljit_uw size)
 98 {
 99         void* retval;
101 #ifdef MAP_ANON
102         retval = mmap(NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANON, -1, 0);
103 #else
104         if (dev_zero < 0) {
105                 if (open_dev_zero())
106                         return NULL;
107         }
108         retval = mmap(NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE, dev_zero, 0);
109 #endif
111         return (retval != MAP_FAILED) ? retval : NULL;
112 }

where it tries to map anonymous memory with PROT_WRITE and PROT_EXEC. Would it be possible to change this according to Ulrich Drepper's suggestion [1] ?

[1] http://www.akkadia.org/drepper/selinux-mem.html
Comment 1 Petr Pisar 2015-12-10 09:38:45 EST
pcre-8.32-15.el7 is affected.
Comment 3 Petr Pisar 2015-12-10 10:16:57 EST
Enhancement request forwarded to PCRE upstream <https://bugs.exim.org/show_bug.cgi?id=1749>.
Comment 7 Remi Collet 2016-11-25 02:57:51 EST
Notice: this may also affects rh-php70 SCL when pcre.jit=1 (but default value is 0)
Comment 8 Petr Pisar 2017-01-12 09:59:28 EST
Upstream is working on the double mapping technique (currently x86, x86_64 and aarch64 JIT compilers work). But the technique has a drawback of a need for temporary files. If a process is not allowed to create them, the JIT compilation will fail. Therefore PCRE applications are still will be advised to cope with unavailable JIT at run time.

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