私は、ユーザープログラムが意図的にLinuxカーネルの状態に影響を与えることができる方法がたくさんあると思います。
- システムコールを呼び出して
- 電話で地図()カーネルにマップされたメモリに書き込みます。
- カーネルモジュールをロードしてモジュールの挿入。
他の方法は思い出されません。ハードウェア割り込みはユーザープログラムによって開始されないため考慮されません。私は両方と思う地図()そしてモジュールの挿入システムコールが使用されているため、ユーザープログラムはカーネルの状態に影響を与えるためにシステムコールに依存する必要があるかもしれません。私は正しいですか？
私が正しい場合は、カーネルにいくつかの脆弱性があり、悪意のあるユーザープログラムがそれを悪用してカーネルを攻撃しようとしているとします。私たちの検証が常に真実を伝えている場合、そのような攻撃を防御するためにすべてのシステムコールを検証できますか？
答え1
別のことが起こります。重要カーネルとのインターフェース：/procおよび/sys仮想ファイルシステム。通常のファイルは保持されませんが、その内容はカーネル用の直接ポータルです。そのファイルに対する作業は、カーネルが割り当てたメモリーで直接作業することです。たとえば、すべてのメモリキャッシュを削除するには、次のようにします。
echo 3 > /proc/sys/vm/drop_caches
...カーネルはすぐに反応します。
プログラムはファイルシステムと対話するためにシステムコール（、、、、openなど）を必要とします。しかし、これらすべてのシステムコールを追跡する方法はまだあります。カーネルはトレースメカニズムを提供します。より具体的には、システムコール追跡はによって処理されます。この仮想ディレクトリには、システムコールごとに2つのサブディレクトリが含まれています。たとえば、オープンシステムコールを使用すると、次のようになります。readwrite/sys/kernel/debug/tracing/sys/kernel/debug/tracing/events/syscalls
sys_enter_opensys_exit_open
このディレクトリ内の名前が「1」のファイルを見つけることができますenable。そのファイルに「1」が含まれている場合は、open関連イベント（開始または終了呼び出し）が追跡されています。私は主にこのenterイベントを利用していますが、あなたのニーズに合ったイベントを選ぶことができます。
システムコールトレースを有効にすると、ログが見つかります/sys/kernel/debug/tracing/trace。今覚えてください開いているシステムコールの使用たくさん。これは、Linuxシステムのすべてになることができるプログラムとファイルの間の究極のゲートウェイです。また覚えておいてください...
UNIXは、ユーザーが愚かなことを防ぐようには設計されていません。なぜなら、そうすれば、ユーザーが賢明なことをするのも防ぐことができるからです。 — ダググウィン
システムで何が起こっているのかを監視することはできますが、カーネルはユーザーが愚かなことを防ぐのを試みません。これはシステム管理者の仕事の多くです。
管理追跡メカニズムには次の権限が必要です/sys/kernel/debug/tracing/trace。トレースを有効にして機能させるには、root 権限が必要な場合があります。完了したら、トレースを無効にすることを忘れないでください。
答え2
時々違うよね"validate" とはどういう意味ですか?特定のプロセスによってトリガーされたシステムコールのみを監視したい場合は可能です。これを行うことができるすべてのツールの1つです。
strace を使用すると、特定のプロセスによってどのシステムコールがトリガーされるかを確認できます。もちろん、rootとして実行する必要があります...しかし、straceはアプリケーションのアクティビティ監視を保護するので、straceを常に正常に実行するわけではありません。 ptrace 呼び出しは削除されます。 Chromeで追跡してみてください。わかります ;)
straceが十分でない場合は、各アプリケーションバイナリを分析し、それが実行する操作を手動で確認できます。これは興味深いでしょう:)
答え3
これは良い最初の近似です。ユーザー空間とカーネルの間には強い境界があり、最大対話にはシステムコールを含める必要があります。このモデルはトラブルstraceシューティングツールで、なぜそれほど強力なのかを理解するのに役立ちます。
多くのカーネルの脆弱性は、これらの検証が不足している可能性があります。このタイプの検証には非常に費用がかかることを理解してください。これは、直接ハードウェアアクセスなどに使用できる言語の場合に特に当てはまります。これは、Cのようなネイティブ言語を使用する場合に特に当てはまります。これは、言語設計がそのような検証に望むよりもはるかに少ない助けを提供するからです。
よく知られた緩和方法は次のとおりです。マイクロカーネル。コードが少ないと、より多くの検証が可能です。マイクロカーネルアーキテクチャを使用すると、大量のデバイスドライバコードがはるかに多く含まれる可能性があります。 IOMMUとMMUが十分であれば、完全にそうかもしれません。
しかし、この声明は正しくありません。
正しい用語を使用して検索すると、反例となる脆弱性がたくさん見つかると思います。まだマップされていないメモリ範囲でエラーが発生する可能性があります。
「Linuxカーネルi386 SMPページエラーハンドラ特権のエスカレーション」[セキュリティチーム]。
通常、すべてのアーキテクチャ固有のエラーコードを確認する必要があります。これには、システムコールとページフォルトを受信するコードが含まれます。ただし、浮動小数点例外（0で除算）などの他の種類のエラーもあります。
さらに、ハードウェアの詳細により脆弱性が発生する可能性があります。コードを確認しようとすると、特定のハードウェアの詳細がわからない場合があります。