web-dev-qa-db-ja.com

Linuxシグナルロガー

カーネルにパッチを適用せずに、Linuxカーネル用のシグナルロガーを探しています。

パッチを当てた記事をたくさん見つけましたが、興味はありません。

デフォルトのUbuntu13.04を実行しています。

# uname -a
Linux bt 3.8.0-26-lowlatency #18-Ubuntu SMP PREEMPT Tue Jun 25 22:36:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

必要なもの：pid、comm（送信者）-> SIGNAL（番号0-31）-> pid、comm（キャッチャー）

あまりにも素晴らしいでしょう：

  pidtree of sender ----- - - - - - receiver(cmd) ---- child1 of receiver, etc
              /                     \----child2---child1 of child2(cmd)
             ppid(+cmd)               ----child3(+cmd)
            /                          \__child4(+cmd)
           ppid of ppid(cmd)
          ....
         /
        init

そしてキャッチャーについても同じです。 +タイムスタンプ。

私がすでに見つけたもの：

superfrink.net：パッチLinux UserSpace Signal Logging（ユーザースペースプログラムから送信された信号をログに記録します。）Chad Clark（バージョン10 2003年3月）

grsecurityパッチにも同様の認識があります。

Ubuntuでこれを実現するための軽くて簡単な方法が必要です。

linuxubuntukernelpatch
5
user42730

私はあなたにそれに対する部分的な解決策を与えることができます。

Linuxカーネルで audit サブシステムを使用します。監査サブシステムは、コアダンプ信号をログに記録します。コアダンプ信号は次のとおりです。

  1. ABRT
  2. FPE
  3. 病気
  4. 終了する
  5. SEGV
  6. トラップ
  7. SYS
  8. EMT
  9. BUS
  10. XCPU
  11. XFSZ

監査ログは/var/log/audit.logにあります。コアダンプ信号の場合、監査ログは次のようになります

type=ANOM_ABEND msg=audit(1386433952.455:141): auid=1000 uid=1000 gid=1000 ses=2 pid=6664 comm="bash" reason="memory violation" sig=24

上記は、uid 1000を使用するユーザーのプロセス6664へのシグナルSIGXCPUで行われるロギングの例です。このログから、「キャッチャー」の通信とpidの詳細を把握できます。ログのreasonフィールドが壊れていることに注意してください。このログがあっても、送信者についてはわかりません。

構成の詳細を見つけることができます ここ

1
PaulDaviesC