如何找出 Apache 尝试“execmem”的原因？

Question

我收到来自 SELinux 的审计消息，说它拒绝 Apache 执行 execmem：

type=AVC msg=audit(05/06/16 19:51:43.058:181060) : avc:  denied  { execmem } for  pid=123456 comm=httpd scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process 

PID 是 Apache PID 之一，它在进程之间不断循环。

从我读到的内容来看，Apache 的 execmem 通常不正常并且是一个坏主意™，这是有道理的。

我已经尝试通过用 Apache 日志记录时间戳来跟踪来源，但是如果影响到各个站点的各种请求（基于 PHP 的有和没有 MySQL，基于 Python/mod_wsgi，加上内部 Apache“OPTION”请求），我不能找到任何一致的东西。

与其试图解释我的设置以让人们对其进行调试，我想知道的是如何确定 execmem 调用的来源，以便我可以确定它是否重要？

（注意：我知道有一个 SELinux 布尔值可以设置为允许它，但我不想在没有先了解它为什么要尝试它的情况下这样做。如果您要将 SELinux 变成一个筛子，就像没有必要拥有防火墙然后打开每个抱怨的端口而不检查它是否重要）。

Answer 1

我最近在使用 PHP7 在 Amazon Linux 上使用 SELinux 时遇到了这个问题。我结合使用了 Russell Coker 出色的 LD_PRELOAD 技巧（拦截 mmap() 调用并触发断言失败）和 gdb（在触发断言失败后立即查看调用堆栈）来检查哪个函数要执行 execmem。

我还得出结论，PHP7 PCRE JIT 是罪魁祸首。将 pcre.jit=0 放在 php.ini 中为我修复了它。

详细步骤

1. 以 root 身份登录您的机器
2. 从https://etbe.coker.com.au/2010/07/12/write-execute-mmap-ld-preload/下载 mmap.c 源代码到 /root/mmap.c
3. 构建代码 gcc -shared -g -fPIC mmap.c -o mmap.so
4. 现在通过 gdb 运行 Apache，拦截 mmap() 调用： LD_PRELOAD=/root/mmap.so gdb /usr/sbin/httpd
5. 你被扔进了gdb。因为 Apache 会派生子进程，所以通过set follow-fork-mode child在 (gdb) 提示符后键入来告诉 gdb 跳转到它们是很重要的
6. 现在通过run在 (gdb) 提示符后键入来启动 Apache
7. 耐心等待，直到某些 HTTP 请求触发代码，然后触发 mmap 中的断言，然后您将返回 gdb。

程序收到信号 SIGABRT，中止。

[切换到线程 0x7ffff7fe9840 (LWP 28370)]

0x00007ffff638d5f7 在 __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56

56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

8. 键入bt(backtrace) 以查看调用堆栈：

(gdb) bt

#0 0x00007ffff638d5f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56

#1 0x00007ffff638ece8 在 __GI_abort () at abort.c:90

#2 0x00007ffff6386566 in __assert_fail_base (fmt=0x7ffff64d6ca8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ffff7bda990 "%s%s%s:%u: || !(prot & 0x2)",

    file=file@entry=0x7ffff7bda985 "mmap.c", line=line@entry=27, function=function@entry=0x7ffff7bda9af "mmap") at assert.c:92

#3 0x00007ffff6386612 in __GI___assert_fail (assertion=0x7ffff7bda990 "!(prot & 0x4) || !(prot & 0x2)", file=0x7ffff7bda985 "mmap.c", line=27ff "function"

    在 assert.c:101

#4 0x00007ffff7bda93e in mmap (addr=0x0, length=65536, prot=7, flags=34, fd=-1, offset=0) at mmap.c:27

#5 0x00007ffff79a6b86 in alloc_chunk (size=65536) at sljit/sljitExecAllocator.c:101

#6 sljit_malloc_exec (size=4440) 在 sljit/sljitExecAllocator.c:204

#7 sljit_generate_code (compiler=compiler@entry=0x555555b14ad0) 在 sljit/sljitNativeX86_common.c:296

#8 0x00007ffff79bf74e 在 _pcre_jit_compile (re=re@entry=0x555555b14650, extra=extra@entry=0x555555b14750) 在 pcre_jit_compile.c:6434

#9 0x00007ffff79c1fc3 在 pcre_study (external_re=external_re@entry=0x555555b14650, options=1, errorptr=errorptr@entry=0x7fffffffa3c8) 在 pcre_study.c:1354

#10 0x00007fffed2edcbc 在 pcre_get_compiled_regex_cache (regex=0x7fffd8a04000) at /usr/src/debug/php-7.0.9/ext/pcre/php_pcre.c:487

#11 0x00007fffed2ef21f 在 php_do_pcre_match (execute_data=0x7fffec419ab0, return_value=0x7fffec419870, global=1) 在 /usr/src/debug/php-7.0.9/ext/pcre/php_5pcre.c:

9. 罪魁祸首很容易确定。堆栈条目 11 为您提供检查 PCRE 的提示，而条目 5 是出错的实际调用。