安全启动：initramfs 验证

Question

根据https://wiki.ubuntu.com/UEFI/SecureBoot Initrd 映像未经过验证。这些信息是最新的吗？这将使整个安全启动完全无用，因为攻击者可以很容易地用记录 LUKS 密码并将其发送给他的 initramfs 替换 initramfs...这反过来会使所有模块签名麻烦并在安全启动上禁用休眠完全荒谬。

如果确实如此，是否有任何启动板错误/功能请求我们可以投票以使安全启动真正安全？

OTOH，如果此声明已过时，验证如何进行？在新内核安装过程中生成 initrd 文件时，用于签名 initrd 文件的密钥对在哪里？哪个组件稍后验证签名？（shim、MOK、GRUB、内核本身？）...或者也许以某种方式使用 PCR 和 TPM？
...内核命令行怎么样？这也必须经过签名/验证才能确保启动安全......

Answer 1

根据我目前对Ubuntu 20.04的了解：

• shim 由 Microsoft 密钥签名并包含 Canonical 密钥。Microsoft 的密钥已预装在 EFI 中，用于验证 shim
• grub 由 Canonical 的密钥签名并由 shim 检查
• 内核由 Canonical 的密钥签名并由 grub 检查

有2种基本情况：

1. 有人值守开机

• 您可以加密您的/boot分区（仅限 LUKS1，Ubuntu 20.04 中不支持 LUKS2。较新的 Grub 将支持 LUKS2，但有一些限制（https://git.savannah.gnu.org/cgit/grub.git/tree/docs/grub .texi#n4554 )) 或有一个带有/和/boot(LUKS1) 的系统分区
• Grub 将要求输入密码来解锁它并initrd从中 读取内核
  • 注意：众所周知，grub2 解密 /boot 的速度很慢（10-20 秒）：我找不到 grub 团队对此问题的官方确认，但有很多关于此问题的线程，并提供了解决方法：不使用加密启动全部或在 luks 标头的第一个槽中具有较低迭代计数的密钥（即： https: //bbs.archlinux.org/viewtopic.php ?id=228865 ）
• /boot这样，通过使用磁盘加密来隐式保护完整的系统完整性/

2. 无人值守开机

• 在这种情况下你无法加密/boot，所以你有 2 个选择
• 签署initrd和内核并强制检查它们：
  • 您可以创建一个 EFI 二进制文件，其中包含所有内容（内核、、initrd）grub.cfg，使用自定义密钥进行签名并将此密钥添加到 EFI 密钥存储中
  • 或者做同样的事情，但不是将所有内容都放入 Grub EFI 二进制文件中，而是只在其中添加一个 GPG 公钥，这是您用来签署grub.cfg、 内核和initrd( https://ruderich.org/simon/notes /secure-boot-with-grub-and-signed-linux-and-initrd）
  • 无论哪种情况，您都必须在每次initrd更新时生成签名甚至 EFI 二进制文件（最好通过initramfs-tools钩子自动生成）
• 如果您不想搞乱签名并拥有 TPM
  • 您可以保持initrd原样/boot，让任何攻击者修改它，但您将根文件系统绑定到适当的 TPM 寄存器，有效地阻止访问（如果rootfs有人更改了内核参数）、任何使用的文件（内核二进制文件、、initrd）grub.cfg...
  • 这里唯一的缺点是，在initrd/kernel 更改后，您必须重新启动，手动解锁磁盘并将 LUKS 上的 TPM 绑定密钥插槽重新绑定到新的 PCR 寄存器值，并确保在此重新启动期间没有人更改任何内容/boot。理想的解决方案是，如果可以计算未来的 TPM 值，并且因此不必保持 luks TPM 绑定。正在解决此问题的项目： https ://github.com/grawity/tpm_futurepcr

一些进一步的分类参考：

• https://www.scitepress.org/Papers/2021/103139/103139.pdf
• https://bugzilla.redhat.com/show_bug.cgi?id=1854177
• https://wiki.ubuntu.com/UEFI/SecureBoot
• https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening
• https://jumpcloud.com/blog/how-to-enable-full-disk-encryption-on-an-ubuntu-20-04-desktop

更新：2022-11-07：添加了一些有关 grub2 限制的来源和详细信息

Answer 2

您甚至不需要签署/验证initramfs，因为您不需要保持它可访问（在本地磁盘上未加密）。

Ubuntu20.04完全能够处理 initrd 文件包含在加密容器内的安装布局（目前适用于AMD64 和 ARM64 上的luks1 、 luks2以及未来版本中的更多平台）。除了降级到具有相同内核的最早版本之外，除了您之外没有人可以修改用您的密码密封的 initrd。

当前自动化中真正缺少的部分是生成用于验证其自身配置的签名 grub 二进制文件。它也可以开箱即用 - grub可以验证 gpg 风格的签名 - 但Canonical提供的内核安装脚本不会以通常的全自动方式进行设置/更新。

如果您想在当前的 Ubuntu 版本中配置经过完全验证的引导链，您可以尝试将您自己的脚本（这是您的配置，然后使用then将该二进制文件gpg --sign集成到 grub 二进制文件中，然后再将其放入）中每当您安装/删除内核（版本）时它都会自动调用。grub-mkstandalonesbsign/boot/efi/etc/kernel/postinst.d/

请注意，几乎没有消费者 PC 实际上用于注册安全启动的自定义密钥 ( MOK )，因此您可能会遇到一些固件错误。您也不会找到太多关于此主题的错误报告，仅仅是因为很少有人想要/做如此复杂且容易出错的事情。

这只是 Ubuntu 方面的事情。在安全方面您可能一无所获（但欢迎您在那里做出贡献）。

Answer 3

您可能需要首先定义威胁模型：您要防范什么？

安全启动应该防止 root 用户破坏以内核级权限运行的代码的完整性。这在启动时最为明显：即使是 root 也不应该能够安装不可信的内核或引导加载程序，并且我们使用签名来确定可信度。然而，它也扩展到正在运行的内核：Ubuntu 内核将检测安全启动并在启动早期进入锁定完整性模式。完整性模式尝试在运行时维护根和内核之间的安全边界。（这会阻止您执行类似kexec从受信任内核到不受信任内核的操作。）

安全启动任务中从未包含过的内容是防止 root 替换非内核二进制文件。这是一个相当困难的问题，脚本语言使它变得更加困难。在自由和开源软件世界中，情况更加令人担忧，因为人们对他们认为限制软件自由的任何事物都感到非常愤怒，即使可以禁用它。（例如，看看苹果公司对几乎所有内容进行签名的做法！）

肯定有一些方法可以限制 root 用户安装恶意二进制文件。您可以使用 grub 的分离签名支持来要求 initrd 进行签名。但是，所有事情，甚至是grub.cfg，都必须签署，这对于管理来说真的很烦人。你可以使用类似的东西dm-verity。IMA 可以帮助你（但对于脚本来说没有那么多）。但你很快就会不再拥有通用系统！