web-dev-qa-db-ja.com

起動時にセキュアブートエラー「イメージが* ACCESS DENIED *で検証に失敗しました」を修正する方法

今朝、マシンを起動したとき(セキュアブートとUEFIのみが有効になっています)、このエラーが表示されました(画像の品質が低くなって申し訳ありません)。

enter image description here

Image failed to verify with *ACCESS DENIED*とはどういう意味ですか? OKを押した後、BIOSにアクセスしてセキュアブートをオフにし、UEFIとLegacyの両方を受け入れるようにUEFIのみのオプションを設定することができましたが、これでうまくいくようでしたが、今は起動しませんセキュアブートが再びオンになり、これがセキュリティ上の脅威になるように設定するために、問題はどこにあるのでしょうか。そして、なぜエラーが発生しましたか?つまり、心配するエラーがありますか?そして、なぜそれが*ACCESS DENIED*私でしたか?

今朝、この問題が発生する前の昨夜、私が考えていた唯一のことは、grubなどのセキュリティアップデートを受け取ることです。

enter image description here

したがって、基本的には、エラーの意味、エラーの原因、およびこの状況を修正する方法を知る必要があります。つまり、このエラーは、何らかの形で侵害されており、新規インストールなどを行う必要があることを意味していますか?それとも単に故障ですか?もしそうなら、どうすればセキュアブートを再び使用できるように修正できますか?

Lenovo B590でUbuntu GNOME 15.10とGNOME 3.18を実行しています。

情報の更新:

コマンドefibootmgrの出力は次のとおりです。

BootCurrent: 000E
Timeout: 0 seconds
BootOrder: 000E,0000,0001,0002,0003,000C,0006,0007,0008,0009,000A,000B,000D
Boot0000  Setup
Boot0001  Boot Menu
Boot0002  Diagnostic Splash Screen
Boot0003  Lenovo Diagnostics
Boot0004  Startup Interrupt Menu
Boot0005  Rescue and Recovery
Boot0006* USB CD
Boot0007* USB FDD
Boot0008* ATAPI CD1
Boot0009* ATA HDD0
Boot000A* ATA HDD1
Boot000B* ATA HDD2
Boot000C* USB HDD
Boot000D* PCI LAN
Boot000E* ubuntu
3
user364819

GRUBパッケージが昨日(2015年12月15日)更新されました:2.02~beta2-29ubuntu0.2
アップグレード中に問題が発生した可能性がありますが、セキュリティ上の問題はないはずです。

BIOS設定を、Ubuntuをインストールした状態に戻します。
次に、GRUBブートローダーをUbuntuインストールにEFIモードで再インストールします。

Ubuntuインストールメディアから起動します-ターミナルを開いて実行します:

Sudo mount /dev/sd*** /mnt
Sudo mount /dev/sd** /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do Sudo mount -B $i /mnt$i; done
Sudo chroot /mnt
grub-install /dev/sd*
update-grub  

注意:

sd* =ディスク| sd** = efiパーティション| sd*** =システムパーティション
ディスクとパーティション番号を識別するには、GPartedを使用できます。

BIOSを起動し、デフォルトのオペレーティングシステムとしてUbuntuを選択します。

USN-Reference: buntu Security Notice 2836-1:GRUB脆弱性

動作しない場合は、代わりにブート修復ツールを試すことができます。
Ubuntuインストールメディアから起動し、ターミナルを開いて実行します。

Sudo add-apt-repository ppa:yannubuntu/boot-repair  
Sudo apt-get update  
Sudo apt-get install -y boot-repair && boot-repair
1
cl-netbox

https://bugs.launchpad.net/bugs/1528345 によると、これはUbuntuがgrubのセキュリティ更新プログラムを誤った方法で出荷したために発生したもので、パッケージgrub-efi-AMD64をインストールすることで修正できます-署名してから、BIOSでセキュアブートを再度有効にします。これは私のために働いた。 (パッケージを再インストールすると、shimx64.efiではなくefibootmgr -vの出力にgrubx64.efiが表示されることも確認しました。

3
David Baron

まず、ファームウェアに戻って、CSM(「レガシーブート」)サポートを無効にします。純粋なEFI環境で起動している場合、そのように聞こえますが、そのオプションは役に立たず、後で戻ってくるかもしれません。 (CSMの問題の詳細については、 テーマのマイページ を参照してください。)

次に、エラーメッセージは、コンピューターが承認されたセキュアブートキーで署名されていないブートローダーを起動しようとしたことを示します。 (このような違反を警告するメッセージの一部はかなり鈍いものです。違反が発生した場所に応じて、EFIごとに異なり、場合によっては後続のプログラムごとに異なります。)コンピュータは正常に起動しており、起動プログラムやファームウェアの設定を変更せずに、大きな赤い旗です。

GRUBまたはShimのアップデートについては言及していないので、ブートプロセスはこれらのアップデートの影響を受けないはずです。 OTOH、他の何かがブートパスを変更した可能性があります。これは、ひどく行ってグリッチを引き起こした無害な変更である可能性があります-たとえば、別のLinuxディストリビューションでトリプルブートしている場合、ブートパスが署名されていないGRUBに変更された可能性があります。その場合は、efibootmgrを使用して、ブート順序をUbuntuのGRUB(Shim経由)に戻すことができます。Sudo efibootmgr -vと入力して、現在のブート順序を確認します(BootOrder行で) )およびオプション(出力の大部分)。 Shimを介して起動するUbuntuの行を見つけ、目的のエントリが-oであり、2つの選択肢がSudo efibootmgr -o 0009,0000,001BBoot0009である場合、Boot0000のように、Boot001Bオプションを使用して順序を変更します。別の可能性は、無関係なWindowsアップデートがGRUBに干渉したことです。 (Microsoftにはほとんどのコンピューターのセキュアブートキーを更新する機能があり、何らかの理由でUbuntuのシムを削除したり、意図的にブラックリストに登録した場合、説明したエラーが表示されることがあります。)

悪意のあることが発生する可能性はわずかです。マルウェアの一部がブートパスに自身をインストールした可能性があります。その場合は、セキュアブートを無効にすることで、マルウェアの実行を既に有効にしていることになります。この場合の結果がどうなるかはわかりません。警戒するつもりはありません。これが起こった可能性は低いです。ただし、このhasが発生した場合は、起動前のマルウェアを取り除くのが難しいため、コンピューターを回復するには専門のTLCが必要です。

GRUB構成を更新しても何の効果もありませんが、GRUBをカーネルの署名なしバージョンからの起動から切り替えた場合、わずかな可能性があります。 (最後にチェックしたのは、UbuntuのGRUBが未署名のカーネルをブートすることですが、将来的には変更される可能性があります。Fedoraで使用されるような他のGRUBはより厳しく、署名されたカーネルのみをブートします)

efibootmgrを使用してブートパスをチェックし、デフォルトでShimを介してブートしていることを確認できます。つまり、ブート順序の最初のアイテムのブートローダーはEFI\ubuntu\shimx64.efiである必要があります。それがnotの場合、起動順序を元に戻すことができるかもしれません。それがisの場合、shimx64.efiバイナリが破損している(または、さらに悪いことにマルウェアに置き換えられている)可能性があります。 GRUBを完全に再インストールすると、問題が解決する場合があります。 (ブート修復はこれをかなり簡単に行うことができます。)

2
Rod Smith