実行可能ファイルの実行開始時に（デジタル署名を使用して）整合性を検証するLinuxセキュリティモジュールの作成を終えたところです。今、私はもう少し深く掘り下げて、実行時にファイルの整合性をチェックしたいと思います（つまり、定期的にチェックします-私は主に開始されて永久に実行されるプロセスを扱っているので...）攻撃者が識別されずにメインメモリ内のファイルを変更できる（少なくともしばらくすると）。
ここでの問題は、ファイルの現在のメモリイメージを確認する方法がまったくわからないことです。上記の私の認証方法は、ファイルが実行前にmmapされるたびに呼び出されるmmap-hookを使用しますが、私が知る限り、LSMフレームワークは定期的なチェックのためのツールを提供していません。
だから私の質問：私がこれをどのように始めるべきかについてのヒントはありますか？メモリイメージを読み取ってその整合性を確認するにはどうすればよいですか？
ありがとうございました
あなたがやろうとしていることは理解していますが、これが正当な理由もなく暖かいファジー感を与えるセキュリティ機能である可能性があることを本当に心配しています。そしてそれらは持つべき最も危険な種類のセキュリティ機能です。（これの別の例は、あなたのすぐ隣に座っているLSM、SElinuxかもしれません。私はこの意見では少数派だと思いますが...）
プロセスのプログラムデータだけが、その動作に影響を与えるわけではありません。悪意のあるコードがスタックに書き込まれてジャンプするスタックオーバーフローは、元のプログラムテキストの整合性チェックを無効にします。攻撃者が元の変更されていないプログラムテキストを有利に使用できるという事実は言うまでもありません。
また、カーネル内でDSAを常に計算している場合は、パフォーマンスの問題が発生する可能性があります。そして、後で悪用される可能性のある特権カーネルコードの長いリストにさらに多くのものを追加しています。
いずれにせよ、質問に対処するために：タイマーで各プロセスをホップしてその整合性をチェックするカーネルスレッドをインスタンス化するカーネルモジュールを作成できる可能性があります。これは、各プロセスのページテーブルを使用し、読み取り専用ページにマッピングし、それらの整合性をチェックすることで実行できます。ただし、何らかの方法ですべてを連結しない限り、各メモリページには独自の署名が必要になる可能性があるため、これは機能しない可能性があります。
共有ライブラリは、それらを使用するすべてのプロセスにわたって再マッピングされるため、スイープごとに1回だけ整合性チェックを行う必要があることに注意してください。ただし、これを実装するには高度な作業が必要になるため、設計のこの「必要な」セクションの下にこれを配置することをお勧めします。
これは良い考えではないかもしれないという私の論理的根拠に同意できない場合、私はあなたの考えに非常に興味があります。少し前にこのアイデアに出くわしたので、新鮮なアイデアを議論に取り入れておくといいでしょう。