背景
Shimはコンパイル中に組み込まれた証明書を持つことができます（「Shimキー」の段落を参照）。ここ）。これにより、ブートローダ/管理者とカーネルは、対応する秘密鍵を使用して署名できます。このアプローチは、これらのコンポーネントからマイクロソフトのUEFI署名を抽象化します。シムにのみMicrosoft署名が必要で、残りには配布署名が必要であるため、信頼チェーンを維持しながら迅速に更新してリリースできます。
ブラックリストに登録
ブートローダ/管理者またはカーネルで脆弱性が見つかった場合は、パッチを適用して新しいバージョンを署名してリリースする必要があります。しかし、もはや同じ署名キーを使用することはできません。そうですか？これにより、shimはまだ脆弱な古いバージョンをロードできます。これらの脆弱性を悪用して任意のコードを実行する可能性がある場合、攻撃者はそれをブートキットに切り替えてセキュリティブートをバイパスする可能性があります。これは、新しい証明書を使用して新しいシムを構築し、セキュアブートのために古いシムのハッシュをdbxにブラックリストに追加する必要があることを意味します。
私はカーネルモジュールがディストリビューションでどのように署名され確認されるのかよくわかりません。ただし、場合によっては、カーネルに組み込まれた証明書に対して署名および確認される可能性があると推測できます。任意のコード実行を許可するモジュールで脆弱性が見つかった場合は、パッチを適用して新しいカーネルキーで署名する必要があります。これは、カーネルが新しいシムキーで署名される必要があることを意味します。つまり、以前のシムを再署名する必要があることを意味します。 。 dbxによってブラックリストに掲載されました。
質問
これは長期的に実行可能なアプローチではないようです。ブートローダ、カーネル、カーネルモジュールの脆弱性は絶えず発見され修正されています。つまり、常に新しいキーペアを作成し、新しい証明書でshimを再構築し、古いshimをブラックリストに登録する必要があります。さらに、セキュアブートが有効になっている場合にユーザーがインストールおよび/または実行できるようにし、セキュアブートデータベースに証明書/ハッシュをインストールするようにユーザーに指示しないすべてのディストリビューションは、ディストリビューションに組み込まれているシムを使用する可能性があります。資格。つまり、上記のコンポーネントのいずれかでランダムなコード実行の脆弱性が見つかるたびに、影響を受けるすべてのディストリビューションに対してshimをブラックリストに追加する必要があります。これは、Microsoftキーを自分のキーに置き換えることができる上級ユーザーにとっては問題ではありませんが、一般ユーザーはセキュリティを維持するためにdbxを常に更新する必要があるようです。ここで本当にそうですか？それとも、組み込みキーを使用する展開数が少なすぎて問題にならないのでしょうか？