为什么 shim/mokmanager 允许规避 SecureBoot 的_所有_保护？以及如何修复它？

Question

这是我所做的：

1. 生成我自己的 SSL 密钥 (db, KEK, PK) x (cer, key)
2. 从内核、GRUB、shim（以及 中的所有其他 EFI 二进制文件/boot）中删除了现有签名，并使用我自己的证书 (db) 对它们进行签名。
3. 重新启动并在 UEFI 中注册我的证书（将其移至用户模式）。

到目前为止，一切都很好。我希望从现在开始，对手只有两种方法来更改我的引导加载程序（GRUB）：

• 转到 UEFI 并禁用 SecureBoot（=> 需要密码）
• 泄露我的私有 KEK 密钥（或 PK），它授权对 db（或 KEK）EFI 变量进行更改，这将允许添加另一个证书，该证书可以签署另一个引导加载程序。

但

现实中发生的情况是，shim 确实检测到 GRUB 已被破坏/修改，它显示了以下内容：

ERROR
Verification failed: (0x1A) Security Violation
<OK>

然后，当我按下 时<OK>，它很高兴地让我添加另一个键（！）

Press any key to perform MOK management

Enroll key from disk

显然，它破坏了整个“信任链”——它使之前的所有步骤变得毫无用处，从某种意义上说，它是一个后门（我知道它试图提供帮助，可能太有帮助了......）。

问题

1. 我对吗？也许我错过了什么或误解了什么？我的印象是，只有密钥的所有者才能更换引导加载程序/EFI/内核（否则，EvilMaid 攻击成为可能，窃取 LUKS 密码变得很容易，等等......）
2. 有解决方法吗？我可以mmx64.efi完全删除MokManager()吗？是否有可能消除这种行为，使其“不那么有帮助”？

聚苯乙烯

以防万一您想知道，那grub.cfg / initrd... - 我正在使用 GRUB 的独立版本来检查它加载的所有内容的 GPG 签名 ( set check_signatures=enforce)

更新

最后我决定完全摆脱这个链：shim-> grub/ grub.cfg> initrd-> linux 内核（因为每个转换都必须经过验证）。

相反，可以直接启动内核（统一内核映像）。更多信息以及工具可以在这里找到。

Answer 1

这是 Thomas Ward （戴着他的服务器团队/开发帽子）代表 Ubuntu 安全团队本身发布的官方回应，从他们的 IRC 频道直接引用转述

Ubuntu 安全团队在回应我向安全团队分类此问题后，已就该问题回复我。我将直接引用安全团队的 Alex Murray（amurray 在#ubuntu-hardenedFreenode IRC 网络上）的话：

这是一个有意的选择，允许用户能够注册自己的证书，因为他们已经辞职了 grub/shim - 如果他们想使用自己的证书等，那么他们应该在没有这个的情况下重建 shim 或者只是删除 mokmanager 二进制文件本身 -由于我们不进行 TPM 支持的全磁盘加密，目前仍有多种方法可以进行邪恶女仆式攻击，这只是其中之一

-- amurray，#ubuntu-hardened，Freenode IRC，2020 年 4 月 26 日 22:25:28 UTC-4

因此，Ubuntu 安全团队承认这是一个风险，但保持原样是有意的选择。

如果您想防止这种情况，请删除mokmanager二进制文件或shim在无法调整证书的情况下重建。

无论哪种情况，Ubuntu 都不执行任何 TPM 支持的全磁盘加密，因此有多种方法可以执行这种“邪恶女仆”式的攻击。虽然 Ubuntu 安全团队承认这一点，但他们并不认为这是需要立即采取行动的事情，因为这是一个有意的选择。

还要记住 -mokmanager向用户发出有关密钥的警告，因此设置系统的用户或管理员要接受风险 - 这可以通过简单地mokmanager完全删除来修复，从而强化系统而不是提供通过此向量更改这些密钥的机制。但是，仍然可以通过其他方式进行此类攻击。