Linuxカーネルイメージでカーネルシンボルを非表示にする方法従順？
カーネルシンボルを非表示にする理由
カーネルの悪用に関する基本的な知識を持つ人なら誰でも、信頼できる悪用のために情報収集がいかに重要であるかを知っています。この保護により、攻撃前の段階での情報収集中に攻撃者が使用できるさまざまな場所からカーネルシンボルが隠されます。 ...このオプションは、複数の/ procエントリを介したカーネルアドレスのリークも防止します。
いくつかの場所は明らかです。 /proc/kallsymsは、sysctl kernel.kptr_restrict=2を使用して制約できます。 /bootフォルダーへのアクセスは、Linuxファイルのアクセス許可を介してrootのみに制限することができ、apparmorを使用してrootから非表示にすることもできます。 AppArmor FullSystemPolicy （ apparmor-profile-everything ）/lib/modules、system.mapなどの他の場所、およびカーネルソースディレクトリ。
非常に具体的な質問をするために、カーネルシンボルがリークする可能性がある他の場所は無視してください。それらを列挙したい場合は、あなた自身の質問をしてください、私が尋ねるかコメントを追加するまで待ってください。
私の非常に具体的な質問は、以下についてです 引用 ：
カーネル[...]は一部のディストリビューションでプリコンパイルされていません
これは、カーネルシンボル カーネルイメージから抽出できる だからです。そのためのオープンソースツールがあります。
（この引用はgrsecurityに関するものですが、私はnon-grsecurity、つまり、ここのkernel.orgからの通常のカーネルについて質問しています。）
Packages.debian.orgなどの公開リポジトリからのカーネルイメージは、攻撃者によく知られています。攻撃者は単にシンボルアドレスをハードコードするだけで、kernel.kptr_restrict=2などの取り組みに対抗できます。
カーネルポインターのリークを防ぐために、カーネルイメージを既知の既知の状態にすることはできません。私が理解している限り、それはユニークでプライベートである必要があります。カーネルを自分でコンパイルする必要があります。
再現可能なビルド は、すべての人のセキュリティを向上させる驚くべき取り組みです。ただし、この場合、Debian linuxカーネルはすでに再現可能であり、ほとんどが再現可能であるか、将来的には完全に再現可能であるため、再現可能なビルドでは、シンボルアドレスがカーネルで再び攻撃者によって予測可能になります（開発に関してはフォローアップしませんでした）それ）。
Linuxカーネルイメージ（vmlinux）のカーネルシンボルを攻撃者から隠す方法は？カーネルに一意のカーネルシンボルがあることを確認するにはどうすればよいですか？そのためのカーネルブートパラメーターはありますか？または、どういうわけかカーネルにランダムファイルを提供して、シンボルをランダム化できるようにすることは可能ですか？または、一意のシンボルアドレスを持つようにカーネルを再コンパイルする方法はありますか？
ディストリビューションのプリコンパイル済みカーネルのレイアウトは公開されています。 KASLRは、秘密のオフセットによってすべてのアドレスを変更して、カーネルのベースオフセットを変更しようとします。残念ながら、1つのシンボルでもリークすると、残りが計算されます。 KASLRは実際のところほど安全ではないため、これは問題です。 infoleaksを介したKASLRバイパスの危険性は、sysctl _kernel.dmesg_restrict=1_を緩和して leak from printk() を設定することによってわずかに減らすことができます。それでも、KASLRはセキュリティ機能が非常に低いため、ローカルの攻撃者からこの情報を確実に隠すために使用することはできません。
カーネルを手動でコンパイルすると、一意のシンボルオフセットを確実に使用できます。 sysctl _kernel.kptr_restrict=2_を設定し、カーネルイメージ自体だけでなく、マップやロード可能なモジュールなどの関連ファイルへのアクセスを制限する必要があります。上流にあるgrsecurityのRANDSTRUCTプラグインを使用すると、カーネル構造の知識に基づく攻撃を少し難しくすることができます。