web-dev-qa-db-ja.com

カーネル：/ dev / kmemおよび/ dev / memを無効にする

/dev/kmemと/dev/memがシステムのメモリ（つまり、未加工のRAM）へのアクセスを提供することを理解しています。カーネルで/dev/kmemを完全に無効にできること、および/dev/memのアクセスを制限できることも知っています。

メモリに直接アクセスできることは、開発者やハッカーにとって役立つ場合がありますが、/dev/memを介してメモリにアクセスする必要があるのはなぜですか。私の知る限り、カーネルでは無効にすることはできません（/dev/kmemとは異なります）。悪用されたり悪用されたりする可能性のある未加工のメモリにアクセスすることは、問題を求めているように思えます。

実用的な使い方はありますか？ユーザープログラムが適切に機能するために必要ですか？

linuxkernelsecuritymemory
8
user1968963

Undermining the Linux Kernel：Malicious Code Injection via/dev/mem これらの2つの箇条書きが含まれているというタイトルの、Scale 7x 2009のスライドデッキがあります。

誰が必要ですか？

  • Xサーバー（ビデオメモリと制御レジスタ）
  • どせむ

これまでに検索で見つけたすべてから、これらの2つの弾丸は合法的な使用のためのフロントランナーであるように見えます。

参考文献

6
slm

/dev/memおよび/dev/kmemを無効にした場合でも、メモリがダンプされることに注意してください。 man procを見て、/proc/kcoreを明らかにしてください。システムの物理メモリです。非常に優れたフォレンジックツールキット rekallには既にこれを行うツールがあります ;メモリ（および/bootファイル）をダンプして、分析できるようにします。

実際のところ、 buntuはデフォルトで/dev/kmemを無効にします ：

/dev/kmemの最近の使用法はありません。これは、攻撃者がカーネルルートキットをロードするためにそれを使用することを超えています。 CONFIG_DEVKMEMは "n"に設定されています。 /dev/kmemデバイスノードは、Ubuntu 8.04 LTSからUbuntu 9.04まで存在しますが、実際にはカーネル内のどこにも接続されていません。

Ubuntuは /dev/memをアプリケーションで必要とするため を無効にしません。

一部のアプリケーション（Xorg）では、ユーザー空間から物理メモリに直接アクセスする必要があります。このアクセスを提供するために、特別なファイル/dev/memが存在します。以前は、攻撃者がrootアクセス権を持っている場合、このファイルからカーネルメモリを表示および変更することが可能でした。 CONFIG_STRICT_DEVMEMカーネルオプションは、非デバイスメモリアクセスをブロックするために導入されました（元々はCONFIG_NONPROMISC_DEVMEMという名前）。

/proc/kcoreを無効にする方法は？

カーネルの構築時にCONFIG_PROC_KCOREを有効にしないでください。

/dev/memを無効にするにはどうすればよいですか？

まあ、man memを見ると、その作成方法の詳細がわかります。

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

rm -rf /dev/memだけを実行できるはずです。 CONFIG_STRICT_DEVMEMを有効にしないことで、カーネルのビルドフェーズ中に無効にすることができます。

/dev/kmemを無効にする方法は？

カーネルのビルド時にCONFIG_DEVKMEMが有効になっていないことを確認してください。

コールドブート攻撃を防ぐ方法は？

/proc/kcore、/dev/mem、/dev/kmemを無効にして、暗号化されたスワップパーティションを使用したり、スワップをまったく使用しなかった場合はどうなりますか？さて、 あなたの記憶はただ凍結される可能性があります そしてその方法でアクセスしました。この攻撃を防ぐにはどうすればよいですか？ RAMを暗号化します。どのようにRAMを暗号化しますか？できません。 詳細はTRESORを参照してください 。

2
user26053

ご存知のように、_/dev/mem_は実行中のシステムの物理メモリへのアクセスを提供します。 _/dev/kmem_は、カーネル仮想メモリへのアクセスを提供します。これらの両方のキャラクターデバイス 永続的に無効にすることができます カーネル構成オプションを介して（コードは最も信頼できる情報源であるため、参照として使用されます）。以下の最初の2つのオプションの設定を解除すると、対応するデバイスが無効になります。

  • _CONFIG_DEVKMEM_ ：_/dev/kmem_がブート時に作成されるかどうかを決定します
  • _CONFIG_DEVMEM_ ：_/dev/mem_がブート時に作成されるかどうかを決定します
  • _CONFIG_STRICT_DEVMEM_ ：_/dev/mem_が存在する場合、アクセスが制限されているかどうかを判別します

ディストリビューションによっては、現在のカーネル構成は_zless /proc/config.gz_またはless /boot/config-$(uname -r)などを使用して確認できます。

_/dev/mem_の最初の意図thinkは memory-mapped 周辺機器との相互作用をサポートすることでした。これらの仮想デバイスを利用できることによる明らかなセキュリティ上の影響（たとえば、攻撃者がその場で別のプロセスのメモリやカーネルにパッチを当てることができる）は、少なくとも10年間知られています。 _/dev/mem_へのアクセスの制限はメインラインカーネルでサポートされています 2008年の初めから 、_/dev/kmem_もオプションです その頃から も。

10年前、Xは_/dev/mem_に依存していたようですが、これはまだ正しいとは思いません。 Xが_/dev/mem_を必要としているという主張をテストするために、昨日、ラップトップから仮想デバイスを削除しましたが、それ以来、一見完璧に機能しています。 2017年にはこれらのデバイスは実際には使用されないようです研究および開発以外では。

セキュリティの観点から、これらのデバイスを削除することをお勧めします。 remote攻撃者は、昇格された特権を使用して、そのアドレス空間外のメモリを読み取ることができることに注意する必要があります。他のユーザースペースアプリケーションのメモリには、 _/proc/<pid>/mem_ を使用してアクセスできます。カーネルメモリには _/proc/kcore_ を使用してアクセスできます。

1
rlf

システムに最初から/dev/memを含めていません。私はGentoo Linuxを使用しているので、このLinuxディストリビューションでは、Linuxカーネルを含むすべてのパッケージを実際に自分でビルドするため、これは驚くに値しないかもしれません。

X.org X11を使用している場合でも、/dev/memがないために問題が発生することはありませんでした。ちょうど今日、パッケージx11-drivers/xf86-video-vesaの-​​ emerge が、次のように/dev/memが必要であることを示すメッセージを出力することに気づきました。

* This driver requires /dev/mem support in your kernel
*   Device Drivers --->
*     Character devices  --->
*       [*] /dev/mem virtual device support

XServer のVESAドライバーを意図的にインストールしなかったため、またはフォールバックとしてのみインストールした場合でも、実際に使用する必要がなかったため、気付かなかった–今まで。

しかし、これはa）X11が/dev/memをもう必要としないこと、およびb）を証明します。 とにかく、一部のX11ビデオドライバーはまだ機能します。

特定のハードウェア用の新しいビデオドライバーは、ほとんどの場合、それがなくても機能します。現代のX.org-X11（Gentooではx11-base/xorg-server）が suid root である必要もないように、これが進行状況のようです...

0
luttztfz