☰

Apacheが "execmem"を試している理由を見つける方法は？

tag-icon • tag-icon apache-httpd selinux
Apacheが

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の1つです。

私が知る限り、Apacheのexcmemは通常次のようになります。珍しいそして悪いアイデア™、言葉になります。

私はApacheログのタイムスタンプを数えてソースを追跡しようとしましたが、さまざまなサイト（MySQLの有無にかかわらず、PHPベース、Python / mod_wsgiベース、および内部Apache "OPTION"）に対するさまざまなリクエストに影響を与えることはできません。要求）一貫したもの。

人々がデバッグできるように私の設定を説明するのではなく私が知りたいのは、execmem呼び出しがどこから来るのかを確認して、それが重要であるかどうかを判断する方法です。

（注：これを許可するように設定できるSELinuxブールがあることを知っていますが、最初にこれを試す理由を理解せずにそれをしたくありません。これをふるいに変えるには、次のものがあります。同じファイアウォールを持つ必要はありません。

ベストアンサー1

最近、PHP7を使用してAmazon LinuxでSELinuxを使用しているときにこの問題が発生しました。私は次の組み合わせを使用しましたラッセルコーカーの素晴らしいLD_PRELOADトリック（mmap()呼び出しを傍受し、アサーションの失敗をトリガーする）とgdb（アサーションの失敗をトリガーした直後に呼び出しスタックを表示）は、目的の関数を確認します。実行メモリ。

私もPHP7 PCRE JITが犯人だと結論付けました。私のためにpcre.jit=0解決しましたphp.ini。

詳細ステップ

  1. rootでコンピュータにログイン
  2. mmap.c以下からソースコードをダウンロードしてください。ここ/root/mmap.cと入力してください。
  3. ビルドコードgcc -shared -g -fPIC mmap.c -o mmap.so
  4. 次に、mmap（）呼び出しを傍受し、gdbを介してApacheを実行します。LD_PRELOAD=/root/mmap.so gdb /usr/sbin/httpd
  5. あなたはgdbに投げられました。 Apacheはサブプロセスを分岐するので、プロンプトset follow-fork-mode childの後に入力してこれらのサブプロセスに移動するようにgdbに指示することが重要です。(gdb)
  6. 次に、プロンプトの後に入力してrunApacheを起動します。(gdb)
  7. 一部のHTTP要求がコードをトリガーするまで、忍耐強く待ってください。コードは順番にgdbでアサーションをトリガmmap()し、gdbに戻ります。
Program received signal SIGABRT, Aborted.

[Switching to Thread 0x7ffff7fe9840 (LWP 28370)]

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

56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
</pre>
8. Type `bt` (backtrace) to see the call stack:
<pre>(gdb) bt

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

#1  0x00007ffff638ece8 in __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 "!(prot & 0x4) || !(prot & 0x2)",

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

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

    at 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) at sljit/sljitExecAllocator.c:204

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

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

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

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

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

<...>
  1. 犯人は簡単に把握できます。スタック項目 11 は PCRE を確認するように求められ、項目 5 は失敗した実際の呼び出しです。

おすすめ記事