I am not any administrator of PCRE, but this sounds like a very specific compile and make option. When I developed the z/OS version, I basically developed such a compile option that was incorporated to the main body with #ifdefYou may be the best expert to develop such an optionZe'ev Atlas
Sent from Yahoo Mail on Android
On Thu, Dec 10, 2015 at 10:15 AM, admin@???<admin@???> wrote:
https://bugs.exim.org/show_bug.cgi?id=1749
Bug ID: 1749
Summary: PCRE-JITted code should be executed from non-writable
memory to obey execmem SELinux restriction
Product: PCRE
Version: 8.38
Hardware: All
URL:
http://www.akkadia.org/drepper/selinux-mem.html
OS: Linux
Status: NEW
Severity: wishlist
Priority: medium
Component: Code
Assignee: ph10@???
Reporter: ppisar@???
CC: pcre-dev@???
Some Linux systems employ SELinux policy that denies obtaining memory pages
that are executable and writable at the same time. Executing an PCRE
application that utilizes PCRE_STUDY_JIT_COMPILE then leads to a crash because.
Example can be network daemon that executes "grep -P". (See
<
https://bugzilla.redhat.com/show_bug.cgi?id=1215701> or
<
https://bugzilla.redhat.com/show_bug.cgi?id=1079534> for real examples.)
This sounds like a trade-off between security and performance and obvious
remedy is to loose the SELinux policy to enable the JIT (for example by
whitelisting "grep" program). However, I was reported that there is another
solution:
As documented on <
http://www.akkadia.org/drepper/selinux-mem.html> (the execmem
case), it's acceptable (from point of view of SELinux) to have an anonymous
file that is mapped twice. First as writable but not executable and second as
read-only and executable. Then one can write the JIT-compiled matching routine
into the writable mapping and then execute it from the read-only mapping. See
the example code in the end of linked document.
The security is fulfilled by the fact that an attacker does not know the
address of the writable memory area because it's independent from program
counter when executing the JITted code.
I'd like to ask PCRE developers if they find this enhancement request
appealing. I know it would require some Linux specific code and some hassle
with creating the anonymous file. But from point of view of system
administrators who have to add exceptions for each PCRE-enabled application
now, it would add significant simplification while keeping the security
standards high.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at
https://lists.exim.org/mailman/listinfo/pcre-dev
