Articles

Ubuntu Wiki

by admin

UEFIセキュアブートとは何ですか？UEFIセキュアブートは、ファームウェアによって起動されたコードが信頼されていることを確認するための検証メカニズムです。

UEFIセキュアブートを適切に安全に使用するには、ブート時にロードされた各バイナリが、バイナリの信頼できるベンダーとソースを示すファームウェアにある既知のキー、または暗号化ハッシュを介して識別できる信頼できる特定のバイナリに対して検証される必要があります。

ほとんどのx86ハードウェアは、Microsoftキーを事前にロードされた工場出荷時から来ています。 これは、一般的にこれらのシステムのファームウェアに依存して、Microsoftによって署名されたバイナリを信頼できることを意味し、Linuxコミュニティはセキュアブー これは、たとえばRed HatとSUSEで使用されているのと同じプロセスです。

ARMやその他のアーキテクチャの多くはUEFIセキュアブートをサポートしていますが、ファームウェアにキーを事前にロードしていない可能性があります。 これらのアーキテクチャでは、ハードウェアの所有者によってファームウェアにロードされた証明書を使用してブートイメージに再署名する必要があ

初期実装計画：実装計画。 amd64:Microsoftによって署名されたshimバイナリとCanonicalによって署名されたgrubバイナリは、Ubuntuメインアーカイブにshim-signedまたはgrub-efi-amd64-signedとして提供されています。 arm64：20.04（’focal’）以降、Microsoftによって署名されたshimバイナリとCanonicalによって署名されたgrubバイナリは、Ubuntuメインアーカイブにshim-signedまたはgrub-efi-arm64-signedとして提供されま これが終了する前に解決する必要がある調査中のGRUBバグがあります。 システムでのセキュアブートのテストに興味がある場合は、こちらのハウツー UEFI/SecureBoot/Testingを参照してください。

UBUNTUでUEFIセキュアブートがどのように動作するか

Ubuntuでは、initrdイメージを除いて、ブートプロセスの一部としてロードされることを目的としたすべての事前ビルドされたバイナリは、CanonicalのUEFI証明書によって署名されています。

microsoftから事前にロードされた署名証明書が利用できないか、ファームウェアにロードされていないアーキテクチャまたはシステムでは、ユーザーはshimまたはgrub上の既存の署名を置き換えて、必要に応じてそれらをロードし、システムのファームウェアにインポートされた独自の証明書と照合することができます。

システムの起動時に、ファームウェアはfirmware BootEntry変数で指定されたshimバイナリをロードします。 Ubuntuはインストール時に独自のBootEntryをインストールし、GRUBブートローダが更新されるたびに更新することができます。 ShimバイナリはMicrosoftによって署名されているため; これは、ファームウェアに既に存在する証明書に対して検証するときに、ファームウェアによって検証され、受け入れられます。 Shimバイナリは正規の証明書とそれ自身の信頼データベースを埋め込むので、ブート環境のさらなる要素は、ファームウェアに事前にロードされた許容可能な証明書のいずれかによって署名されることに加えて、正規のUEFIキーによって署名されることができます。

shimによってロードされた次のものは、第二段階の画像です。 システムが正常に起動している場合は、GRUBのいずれかです; またはmokmanager、キー管理が必要な場合は、ファームウェア変数によって構成されます（通常はシステムが以前に実行されていたときに変更されます）。

正常に起動している場合;GRUBバイナリ(grub*.efi)がロードされ、以前に知られていたすべての信頼されたソースに対して検証が試行されます。 Ubuntu用のGRUBバイナリは、正規のUEFIキーによって署名されているため、正常に検証され、起動プロセスが続行されます。

キー管理タスクを続行するために起動する場合は、MokManagerバイナリ（mm*。efi)がロードされます。 このバイナリは、shimバイナリの構築中にのみ存在する一時キーによって署名されることによって、shimによって明示的に信頼されます。 これは、特定のshimバイナリで構築されたMokManagerバイナリのみが実行できることを意味し、侵害されたツールの使用から侵害の可能性を制限します。 MokManagerでは、システムコンソールに存在するすべてのユーザーが、shimレベルでキーの登録、信頼できるキーの削除、バイナリハッシュの登録、セキュアブート検証のトグル このようなパスワードは、shim/MokManagerの単一の実行でのみ存続し、プロセスが完了またはキャンセルされるとすぐに消去されます。 キー管理が完了すると、システムは再起動され、起動を正常に完了するためにキー管理の変更が必要になる可能性があるため、単に起動を続行するだけで

システムがGRUBへの起動を続けると、GRUBプロセスは必要な設定をロードします(通常はESP(EFIシステムパーティション)から設定をロードし、ルートまたはブートパーティ

この時点までのEFIアプリケーションは、信頼されたファームウェア変数の変更へのアクセスを含むシステムファームウェアへのフルアクセスを持 公式のUbuntuカーネルは正規のUEFIキーによって署名され、それらは正常に検証され、制御はカーネルに渡されます。 Initrdイメージは検証されません。

非公式カーネル、またはユーザーによって構築されたカーネルの場合、ユーザーがUEFIセキュアブートの完全な機能を保持しながらそのようなカーネルをロードしたい UEFIセキュアブートが有効になっているときにGRUBがロードできるようにするには、すべてのカーネルに署名する必要があるため、ユーザーは独自の署名を続行す あるいは、’sudo mokutil–disable-validation’を使用し、プロンプトが表示されたらパスワードを入力して再起動することで、公式カーネルでセキュアブートを有効にして起動している間にshimの検証を無効にしたり、ファームウェアでセキュアブートを完全に無効にしたりすることもできる。

これまで、ロードするイメージの検証に失敗すると、ブートプロセスを停止する重大なエラーが発生します。 システムは起動を継続せず、他のBootEntry変数に有効で信頼できるブートパスが含まれている可能性があるため、一定期間後に自動的に再起動する可能性があ

ロードされると、検証されたカーネルはファームウェアのブートサービスを無効にするため、特権を落とし、効果的にユーザーモードに切り替わります。 カーネルモジュールに与えられる広範な権限を考えると、カーネルに組み込まれていないモジュールもロード時に検証する必要があります。 公式のカーネルでCanonicalによって構築され、出荷されたモジュールは、Canonical UEFIキーによって署名され、信頼されています。 カスタムビルドモジュールは、カーネルによってロードが許可される前に、モジュールに署名するために必要な手順を実行する必要があります。 これは、’kmodsign’コマンドを使用することで実現できます。

符号なしモジュールは単にカーネルによって拒否されます。 Insmodまたはmodprobeでそれらを挿入しようとすると、エラーメッセージで失敗します。

多くのユーザーが自分のシステムが正常に動作するか、一部のデバイスが機能するためにサードパーティのモジュールを必要とすることを考えると; そして、これらのサードパーティ製のモジュールは、実行中のカーネルに適合するようにシステム上でローカルに構築する必要があることを、Ubuntuは署名プロセ ドライバの非自動署名を行うにはどうすればよいですか？

一部のプロジェクトでは、DKMSで動作するように設定されていないカスタムカーネルドライバの使用が必要な場合があります。 これらの場合、shim-signedパッケージに含まれているツールを利用する必要があります。update-secureboot-policyスクリプトは、新しいMOKを生成するために利用できます（DKMSで構築されたモジュールが既に生成をトリガーしていない場合）。

次のコマンドを使用して、既存のキーをshimに登録します。

sudo update-secureboot-policy --enroll-key

MOKが存在しない場合、スクリプトはその旨のメッセージで終了します。 キーがすでに登録されている場合、スクリプトは終了し、何もしません。 キーが存在するが、登録されていることが示されていない場合は、キーを登録できるように、再起動後に使用するパスワードの入力を求められます。

次のコマンドを使用して新しいMOKを生成できます。

sudo update-secureboot-policy --new-key

新しく生成されたキーを、そのタスクの前述のコマンドでshimに登録します。 カーネルモジュールは、ビルドプロセスの一部としてKMODSIGNコマンド(UEFI/SecureBoot/Signingを参照)を使用して署名できます。

カーネルモジュールは、ビルドプロセスの一部とし

マシン所有者の鍵管理におけるセキュリティへの影響

インストール時またはアップグレード時に生成されたMOKはマシン固有であり、KERNELま

最近のshimバージョンには、モジュール署名のみのキーの制限に従うロジックが含まれています。 これらのキーはshimの信頼データベースのファームウェアに登録できますが、shimまたはGRUBがファームウェアにロードするイメージを検証するときは無視されます。 Shimのverify()関数は、”Module-signing only”(1.3.6.1.4.1.2312.16.1.2)KeyUsage OIDを含まないキーによって署名されたイメージのみを正常に検証します。 Ubuntuカーネルはglobal trustデータベース(shimとファームウェアの両方を含む)を使用し、カーネルモジュールをロードするときに含まれているキーのいずれかを署名キーとして受

自動的に生成されるMOKに課される制限と、システムへのスーパーユーザアクセスとシステムコンソールへのアクセスを持つユーザーが、キーを登録するときに必 これは、悪意のあるユーザーやスクリプトによる署名のためのMOKへのアクセスを制限するのに十分であると考えられます。 これにより、生成されたMOK鍵の誤用から悪意のあるカーネルモジュールへの署名までの妥協の可能性が制限されます。 これは、システムへのスーパーユーザーアクセスですでに可能なユーザーランドアプリケーションの侵害と同等であり、これを保護することはUEFIセキュアブートの範

以前のシステムでは、shimでセキュアブート検証が無効になっていた可能性があります。 アップグレードプロセスの一環として、これらのシステムは、shimでSecure Boot validationを再度有効にし、必要に応じて新しいMOKキーを登録するように移行されます。

MOKの生成と署名プロセス

キーの生成と署名プロセスは、我々はブランドの新しいインストールまたは以前にUbuntuを実行しているシステムのアッ

いずれの場合も、システムがUEFIモードで起動していない場合、特別なカーネルモジュールの署名手順やキー生成は行われません。

セキュアブートが無効になっている場合、ユーザーが後でセキュアブートを有効にする可能性があるため、MOKの生成と登録が引き続き行われます。 そうであれば、彼らはシステムが正常に動作するはずです。

ユーザーはUbuntuを新しいシステムにインストールします

ユーザーはインストーラを実行します。 初期段階では、インストールの準備時に、システムがサードパーティのモジュールを動作させる必要がある場合にのみ、インストールが完了した後に必要とされていると明確にマークされたシステムパスワードの入力を求められ、システムがインストールされている間に、ユーザーの操作なしに新しいMOKが自動的に生成されます。

システムに必要なサードパーティドライバまたはカーネルモジュールは、パッケージのインストール時に自動的にビルドされ、ビルドプロセスには署名ステッ 署名ステップでは、以前に生成されたMOKを使用してモジュールに署名するために自動的に使用されるため、システムが再起動され、MOKがシステムの信頼

インストールが完了し、システムが再起動されると、最初の起動時に、ユーザーはすべてのユーザーが生成されたMOKを登録するテキストモードパネルのセッ ユーザーは”Enroll MOK”を選択し、登録する証明書の指紋が表示され、登録を確認するように求められます。 確認されると、新しいMOKがファームウェアに入力され、ユーザーはシステムを再起動するように求められます。

システムが再起動すると、登録したばかりのMOKによって署名されたサードパーティ製のドライバが必要に応じてロードされます。

ユーザーは、UEFI対応のUbuntuシステムを、システムにサードパーティのドライバが必要な新しいリリースにアップグレードします

アップグレード時に、shimおよ Shim署名されたパッケージのインストール後のタスクは、新しいMOKを生成するために進み、アップグレードプロセスが完了し、システムが再起動されると、必

アップグレード中に、カーネルパッケージとサードパーティモジュールがアップグレードされます。 サードパーティ製のモジュールは新しいカーネルのために再構築され、ビルド後のプロセスは自動的にMOKでそれらに署名するために進みます。

アップグレード後、ユーザーはシステムを再起動することをお勧めします。

再起動時に、ユーザーは、すべてのユーザーが生成されたMOKを登録するテキストモードパネルのセットとして、MokManagerプログラム（インストールされたshimローダーの一部） ユーザーは”Enroll MOK”を選択し、登録する証明書の指紋が表示され、登録を確認するように求められます。 また、ユーザーにはセキュアブート検証を再度有効にするためのプロンプトが表示されます（無効になっていることが判明した場合）。MokManagerは再びユーザーからの確認 すべてのステップが確認されると、shim検証が再び有効になり、新しいMOKがファームウェアに入力され、ユーザーはシステムを再起動するよう求められます。

システムが再起動すると、登録したばかりのMOKによって署名されたサードパーティ製のドライバが必要に応じてロードされます。

いずれの場合も、UEFIセキュアブートを有効にし、最新バージョンのshimを使用してシステムを実行すると、新しいDKMSモジュール（サードパーティドライバ）のインス 有効なMOKキーがシステムに存在し、すでに登録されているように見える場合、これはユーザーの操作なしで発生します。

MOKが存在しない場合、または既存のMOKが登録されていない場合は、署名の直前に新しいキーが自動的に作成され、再起動時に必要なパスワードを入力してキーを登録するように求められます。