安全启动实际上是如何工作的?

Jum*_*ays 6 boot grub2 signature grub-efi secure-boot

我正在使用 GRUB2、SecureBoot 和 Kernel Signing,我想我在安全启动中发现了一个可能的错误,但我想先检查一下我对这些过程的理解。

我知道启用安全启动后,只能启动使用固件中加载的密钥签名的二进制文件,因此必须对所有引导加载程序进行签名。在典型的情况下是 shim 和 GRUB。

如果引导失败或者您有一些密钥要导入或删除,Shim 应该启动 MoakManager,如果一切正常,它应该启动 GRUB,它是真正的引导加载程序。

问题是我刚刚生成了一个自定义版本的 GRUB grub-mkstandalone,我用它用 OpenSSl 创建的新密钥进行了签名;我尚未在固件中导入的密钥,并且 shim 能够在没有来自安全启动的任何报告的情况下启动它。

我检查了密钥,mokutil --list-enrolled它只报告了规范证书。


所以,回顾一下:

在我的 EFI 分区中,我有:

  • shimx64.efi 由 Canonical 签名,由 grub-install 生成
  • 我的自定义 GRUB,用 grub-mkstandalone 生成,用我自己的密钥签名,我还没有导入,名为grubx64.efi.

在引导时,SHIM 可以午餐 GRUB,而 GRUB 可以成功引导 Ubuntu。

如果某些 Secure Boot 只检查第一个引导加载程序的标志,而其他加载程序负责验证它们自己以及它们预加载和用户最终加载的模块,那么这里的安全问题就非常高。

我会做更多的测试,但也许我应该打开一个错误票。


有任何想法吗?

Rod*_*ith 4

我相信您的理解是正确的,除了shimx64.efi通过包以二进制形式交付,而不是通过本地生成grub-install。(不过grub-install,很可能会安装 shimx64.efi到 ESP。)哦,它是 MokManager,而不是 MoakManager。

在提交错误报告之前,您应该回顾您的步骤并 100% 确定您是通过本地编译的 GRUB 引导的。efibootmgr例如,很容易意外地将二进制文件放在错误的位置或忽略运行以调整启动顺序。(你还没有描述你是如何安装你的定制的grubx64.efi——你是覆盖标准的 Ubuntu 二进制文件还是将你的新二进制文件放在其他地方并通过注册它[和 Shim 的副本] efibootmgr?)你可能想运行sudo efibootmgr -v来查看你的启动细节。请注意 和BootOrderBootCurrent——前者告诉您尝试启动选项的顺序,后者显示用于启动计算机的选项。您需要将数字与Boot####描述每个启动选项的各行进行交叉引用。如果您将自己的 GRUB 与 Ubuntu 的 GRUB 分开安装,则可以想象固件会由于安全启动错误而默默地绕过它,然后退回到现有的 Ubuntu Shim/GRUB,这可以解释您所看到的情况。

另一种可能性是您的计算机实际上并未启用安全启动。您可以按如下方式检查这种可能性:

$ hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c 
0000000 0016 0000 0001              
0000005
Run Code Online (Sandbox Code Playgroud)

在此示例中,输出 ( ) 的第一行0000000 0016 0000 00011. 这表明安全启动已激活。如果它以 结尾0,则您的计算机上已禁用安全启动。

另一种可能性是您可能以某种方式将本地密钥安装在固件自己的数据库列表中。不过,这是一项艰巨的任务,因此您不太可能在没有意识到的情况下无意中完成了它。(有关如何设置的详细信息,请参阅我关于该主题的页面。)我提到这种可能性主要是为了完整性;我觉得这根本不可能,除非你忽略了之前以这种方式掌握安全启动的尝试。

如果您发现错误,它可能存在于 Shim 或固件中。

还有一点需要注意的是,我对 GRUB 特定的工具(例如grub-mkstandalone. 由于我维护 rEFInd,所以我更喜欢使用它,因此我对 GRUB 工具的了解并不像想象的那么深入。因此,我可能会遗漏一些关键细节,因为它是 GRUB 特定的。