最近、モジュールを手動で署名する必要があるドライバーをインストールしたのですが、そのモジュールに署名すると実際に何が行われるのか、なぜ署名する必要があるのかがわかりません。
このプロセスに関する他の質問もここにありますが、それらはより技術的なものです。モジュールの署名が何をするのか、なぜそれが必要なのか、また代替手段は何なのか (どうやら dkms はモジュールに自動的に署名できるようです) について簡単に説明してください。
答え1
カーネルは、署名されていないモジュールや誤って署名されたモジュールが使用された場合に警告するだけ (ログ メッセージ + カーネルに汚染フラグを設定する) にするか、カーネルが検証できる署名を持たないカーネル モジュールを完全に拒否するように設定できます。
BIOS スタイルのブート プロセスを使用する場合、またはセキュア ブートを無効にして UEFI を使用する場合、これは基本的にオプションの追加セキュリティ手順にすぎません。これにより、侵入者が悪意のあるカーネル モジュール (侵入者のツールやアクションを隠すためのカーネル ベースのルートキットなど) をシステムに追加することが多少難しくなります。
しかし、セキュア ブートを有効にした UEFI を使用する場合、これはセキュア ブートの要件の一部です。セキュア ブートの「精神」は、信頼できないコードをカーネル空間にロードできないようにすることです。UEFI ファームウェアは、ブートローダ上で有効な署名 (またはホワイトリストに登録された SHA256 ハッシュ) が存在するかどうかを確認します。ブートローダは OS カーネル上で同じものをチェックする必要があります。また、カーネルはこの要件をカーネル空間で実行されるすべてのコードに拡張する必要があります。
もちろん、実際には OS カーネルはこの要件を簡単にオプトアウトできます。しかし、セキュア ブートを開発した組織は、このオプトアウトには少なくともシステム管理者からの明確なアクションが必要であると決定しました。デフォルトでは署名要件を強制する必要があります。
(ちなみに、これは、最新の Windows ではインストールされたドライバーがデフォルトで署名されている必要がある理由の 1 つでもあります。署名されていないドライバーをインストールする場合は、管理者アクセスを必要とする設定を明示的に変更する必要があります。)
セキュアブートシステム上で起動可能で、署名されていないカーネル空間コードを「そのまま」実行できるツールは、セキュアブート回避デバイスマルウェアとして分類される可能性があります。
Microsoft は最もよく知られているセキュア ブート署名者であり、shimx64.efi署名要件を強制する shim ブートローダーのバージョンのみに署名します。
セキュア ブート対応の UEFI ファームウェアには、ファイルが使用する Microsoft PE+ バイナリ形式を使用するバイナリの署名をチェックする機能が組み込まれています*.efi。ただし、Linux の世界では一般にそのバイナリ形式は使用されず、代わりに ELF バイナリ形式が使用されます。
Linux カーネル モジュールと GNU GRUB ブートローダ モジュールは両方とも ELF 形式に基づいています。このため、ブートローダとカーネルは ELF バイナリ用の独自の署名チェック アルゴリズムを提供する必要がありますが、どうやら UEFI フォーラム (UEFI およびセキュア ブート仕様を管理する業界コンソーシアム) は、有効な署名のデフォルト要件が維持される限り、それを実行しても問題ないと決定したようです。
もちろん、DKMS を使用してカーネル モジュールを自動的に構築して署名する場合、これは期待どおりには機能しません。つまり、有効な署名を自動的に生成するために使用できる秘密キーを含む証明書が存在するため、侵入者はそれを使用して悪意のあるカーネル モジュールに署名することもできます。セキュア ブートのないシステムよりも安全性が低いわけではありませんが、それほど安全でもありません。
複数のシステムがある場合、モジュール署名証明書の秘密鍵を 1 つのホスト (おそらく攻撃者による脅威が最も少ないホスト) にのみ保持し、それを使用して必要なカスタム カーネルやモジュールを構築し、そこからそれらを必要とする他のホストに配布することで、セキュリティ上の利点を得ることができます。 こうすることで、他のホストではモジュール署名証明書の公開部分のみが必要になります。これは、既存の署名を検証するためにのみ使用でき、新しい署名を作成するためには使用できません。