☰

システムコールは、ユーザープログラムが意図的にLinuxカーネルの状態に影響を与える唯一の方法ですか？

tag-icon • tag-icon linux kernel security linux-kernel system-calls
システムコールは、ユーザープログラムが意図的にLinuxカーネルの状態に影響を与える唯一の方法ですか？

私は、ユーザープログラムが意図的にLinuxカーネルの状態に影響を与えることができる方法がたくさんあると思います。

  1. システムコールを呼び出して
  2. 電話で地図()カーネルにマップされたメモリに書き込みます。
  3. カーネルモジュールをロードしてモジュールの挿入。

他の方法は思い出されません。ハードウェア割り込みはユーザープログラムによって開始されないため考慮されません。私は両方と思う地図()そしてモジュールの挿入システムコールが使用されているため、ユーザープログラムはカーネルの状態に影響を与えるためにシステムコールに依存する必要があるかもしれません。私は正しいですか？

私が正しい場合は、カーネルにいくつかの脆弱性があり、悪意のあるユーザープログラムがそれを悪用してカーネルを攻撃しようとしているとします。私たちの検証が常に真実を伝えている場合、そのような攻撃を防御するためにすべてのシステムコールを検証できますか？

ベストアンサー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_open
  • sys_exit_open

このディレクトリ内の名前が「1」のファイルを見つけることができますenable。そのファイルに「1」が含まれている場合は、open関連イベント（開始または終了呼び出し）が追跡されています。私は主にこのenterイベントを利用していますが、あなたのニーズに合ったイベントを選ぶことができます。

システムコールトレースを有効にすると、ログが見つかります/sys/kernel/debug/tracing/trace。今覚えてください開いているシステムコールの使用たくさん。これは、Linuxシステムのすべてになることができるプログラムとファイルの間の究極のゲートウェイです。また覚えておいてください...

UNIXは、ユーザーが愚かなことを防ぐようには設計されていません。なぜなら、そうすれば、ユーザーが賢明なことをするのも防ぐことができるからです。 — ダググウィン

システムで何が起こっているのかを監視することはできますが、カーネルはユーザーが愚かなことを防ぐのを試みません。これはシステム管理者の仕事の多くです。

管理追跡メカニズムには次の権限が必要です/sys/kernel/debug/tracing/trace。トレースを有効にして機能させるには、root 権限が必要な場合があります。完了したら、トレースを無効にすることを忘れないでください。

おすすめ記事