（モジュールなしで）カーネルを直接変更するLinuxルートキットが流通していますか？
Linuxで動的カーネルモジュールのロードを無効にすると、セキュリティが向上すると言われてきました。私は人々がこのアドバイスをする理由を理解していますが、モジュールのインターフェイスが利用できない場合、悪意のある人が直接メモリを変更できるといつも思っていました。 （結局のところ、ロード可能なモジュールインターフェイスは善良な人のためのものです。）
だから私の質問はこれです：モジュールインターフェイスを使用するのではなく、カーネルメモリを直接変更する循環ルートキットを知っている人はいますか？
はい、あります。Phrackで紹介されている suckit rootkit はそのような例の1つで、/dev/kmemを介してLinuxカーネルを変更します。基本的に、目標は同じままです。システムコールテーブルのエントリを置き換えて、やりたいことを実行します。ここでの違いは、変更が/dev/kmemを介して行われることです。
カーネルのgrsecurity/PaXパッチには、/dev/kmem、/dev/mem、および/dev/portへのアクセスを無効にするためのサポート/構成が含まれます。 ここのエントリ を参照してください。
/dev/memと/dev/kmemの違い ここで説明 。
このようにメモリを変更することとカーネルモジュールにロードすることの顕著な違いは、シンボルの露出です。ほとんどのカーネルモジュールルートキットはstatic関数でコンパイルされているため、これらの関数はコードからエクスポートされません。ただし、カーネルモジュールの存在を裏切る可能性のある他の手法もあります（たとえば、init関数はエクスポート可能である必要があります）。カーネルメモリを直接変更するルートキットは、カーネルアドレス空間のスキャンでは表示されませんexcept変更された部分（つまり、syscallテーブルがどこを指し、何を指しているのかがわかっている場合）作成者が/dev/kmemをさらに読み取って正しいアドレスを提供することを保証するほど賢い場合を除いて、それを検出する可能性があります。
悪者がメモリを直接変更できるかどうかについて-ルートプロセスは技術的にはまだユーザー空間にあります。つまり、まだリング3の一部であり、仮想メモリサンドボックスをエスケープする機能はありません。リング3プロセスが変更できる唯一のメモリは、それ自身の仮想アドレススペースです。これは、それに関してはメモリはどのように見えるかです。リング3プロセスは、マークされたメモリのすべてのルールに従う必要があります。たとえば、ページが読み取り専用としてマークされている場合、プロセスによって変更することはできません（CPUが拒否し、OSに通知します）。ただし、リング0プロセス（CPUスーパーバイザーモード）は、任意のメモリを変更でき、メモリページのステータスを無視するようにCPUに要求することもできます（つまり、ファクトページが読み取り専用であることを無視できます）。
だから私が手に入れようとしているのは、ルートプロセスはルートプロセスであることを介してメモリに暗黙的にアクセスできないことです-それでもカーネル経由でそのようなアクセスを要求して取得する必要があります。カーネルが盲目的に従うだけです。したがって、1つの解決策は、PaXパッチを使用して、カーネルにそのような要求を拒否させることです。