这是一个创建于 1887 天前的主题，其中的信息可能已经有所发展或是发生改变。
先划重点: 不校验 initrd/initramfs. shim, grub, kernel, kernel module 都有验证, 就 initramfs 没验证.
反正 RHEL 的 initramfs 被修改后启动还是显示 secure boot enabled. /滑稽 /
ubuntu 安装时有一个 "配置 secure boot" 的选项, 但不知道啥用.
还是继续 archlinux 算了, bootloader + kernel + initrd + cmdline 打包成一个 efi 文件并签名. 骗自己完全够了.
 |
1
flynaj 2019-10-24 21:34:09 +08:00 via Android
kernel 后面已经没有办法验证了，Windows 也一样。
|
 |
2
Osk OP @flynaj 感谢提醒, 被这两家文档里轻飘飘的一句: 不验证 initramfs 给震惊到了, 没说明白.
windows 确实也是一样, 网上一大把 PE 不需要关闭 secure boot 来启动. Linux 的 secure boot 也不验证 user space 的程序. 我一直觉得 secure boot 只是整个安全加固中的一环, 而不是全部. 在启动过程中需要输入 OS 分区密钥的情况下 SB 比较有用: 对于 Windows 来说, secure boot 验证了 bootmgr, bootmgr 会让用户输入密码解密加密的 C 盘(或者使用 TPM 测量启动环境以自动解密), 由于 ms 公开的细节比较少, 就目前看来这个流程是可信的. 当然, 可能有我不知道的漏洞能发起攻击, 欢迎各位告知. 对于 Linux 来说, 就坑爹了, 由于 OS 架构不一样, Linux 的 LUKS 解密是 User Space 的程序询问密码并解密的(TPM: 我是谁, 我在哪?🤣), 这个操作在 initramfs 中完成, 而 rhel/ubuntu 的 secure boot 实现并不验证 initramfs, 那么攻击者可以修改 initramfs, 在合适的时机(比如询问密码是做记录或 switch_root 前向目标 rootfs 中植入恶意程序), 那么 SB 除了让插入自己的 ko 变得更麻烦外, 意义何在? ArchLinux 这边有一个趣的方案: 把 Kernel、initramfs、ucode、cmdline 等嵌入到 systemd 的 boot manager 中, 然后对这个打包的 efi 签名, 这样就避免了 initramfs/cmdline 被篡改的可能, 不过这个方案目前操作略复杂... |
 |
3
msg7086 2019-10-25 02:52:06 +08:00
只知道以前 Linux 的“支持”SB 是指之前 UEFI 被强推 SB 会导致没有签名的 Linux 无法引导的问题。“支持”SB 就是最开始的 Boot loader 拿到签名通过 UEFI 验证使之可以正常引导。如果缺少 SB 支持的话，在强制打开 SB 的机器上就无法启动了。
|
Select Language