![Linux 引导加载程序支持全盘加密吗?](https://linux22.com/image/42162/Linux%20%E5%BC%95%E5%AF%BC%E5%8A%A0%E8%BD%BD%E7%A8%8B%E5%BA%8F%E6%94%AF%E6%8C%81%E5%85%A8%E7%9B%98%E5%8A%A0%E5%AF%86%E5%90%97%EF%BC%9F.png)
是否有支持全盘加密的 Linux 引导加载程序(a la真密)。我知道有人正在努力向 GRUB2 添加加密支持,但这似乎还没有准备好。还有其他选择吗?
(请注意,我在这里真正指的是全盘加密 - 包括/boot
)
大多数答案描述了/boot
未加密的设置,其中一些答案试图解释为什么未加密/boot
应该没问题。
无需讨论为什么我实际上需要 /boot 进行加密,这里有一篇文章基于 GRUB2 的修改版本准确描述了我的需要:
问题在于,当前 GRUB2 代码库显然不支持这些修改(或者也许我忽略了某些内容)。
答案1
我认为当前版本的 GRUB2 本身不支持加载和解密 LUKS 分区(它包含一些密码,但我认为它们仅用于密码支持)。我无法检查实验开发分支,但 GRUB 页面中有一些提示,计划进行一些工作来实现您想要做的事情。
更新(2015):最新版本的 GRUB2 (2.00) 已经包含访问 LUKS 和 GELI 加密分区的代码。 (OP 提供的 xercesch.com 链接提到了第一个补丁,但它们现在已集成在最新版本中)。
但是,如果您出于安全原因尝试加密整个磁盘,请注意,未加密的引导加载程序(如 TrueCrypt、BitLocker 或修改后的 GRUB)并不提供比未加密/boot
分区更多的保护(如 JV 在上面的评论中所述) 。任何能够物理访问计算机的人都可以轻松地将其替换为自定义版本。您链接的 xercestech.com 文章中甚至提到了这一点:
需要明确的是,这并不会以任何方式使您的系统不易受到离线攻击,如果攻击者用自己的引导加载程序替换您的引导加载程序,或重定向引导过程以引导他们自己的代码,您的系统仍然可能受到损害。
请注意,所有基于软件的全磁盘加密产品都存在此弱点,无论它们是否使用未加密的引导加载程序或未加密的引导/预引导分区。即使是支持TPM(可信平台模块)芯片的产品,例如BitLocker,也可以在不修改硬件的情况下进行root。
更好的方法是:
- 在 BIOS 级别解密(在主板或磁盘适配器或外部硬件 [智能卡] 中,带或不带 TPM 芯片),或
/boot
在可移动设备(如智能卡或 USB 记忆棒)中携带 PBA(预启动授权)代码(本例中为分区)。
要采用第二种方法,您可以在以下位置查看 Linux 全盘加密 (LFDE) 项目:http://lfde.org/它提供了一个安装后脚本,用于将/boot
分区移动到外部 USB 驱动器,使用 GPG 加密密钥并将其也存储在 USB 中。这样,引导路径的较弱部分(非加密/boot
分区)始终与您在一起(您将是唯一能够物理访问解密代码和密钥的人)。 (笔记:该网站已丢失,作者的博客也消失了,但是您可以在以下位置找到旧文件https://github.com/mv-code/lfde请注意,最后一次开发是在 6 年前完成的)。作为一种更简单的替代方案,您可以在安装操作系统时将未加密的启动分区安装在 USB 记忆棒中。
问候,MV
答案2
使您的初始 RAMdisk 和 /boot 文件夹不使用加密。
这将启动一个“最小”内核,其中包含驱动程序和支持以切换到“实际”根文件系统是加密的。
在你声称“这是一个黑客”之前 - 请记住 - 大多数(如果不是全部)Linux 发行版今天默认以这种方式启动。这明确允许您的系统使用需要从文件系统加载的模块来引导和加载根文件系统。 (有点像先有鸡还是先有蛋的问题)。例如,如果您的根文件系统位于硬件 RAID 卷上,并且您需要先加载其驱动程序,然后才能挂载根 FS。
答案3
我查看了您发布的链接 - 尽管没有启动分区,但硬盘上仍然有一个未加密的启动加载程序,可以使用邪恶女仆攻击来访问和破坏。我一直在研究类似的设置,其中硬盘上没有未加密的数据,但到目前为止我只提出从可移动驱动器运行引导加载程序。
答案4
不,我认为没有。
你真的需要加密/boot吗?我怀疑不是。文件系统的其余部分可以通过普通的 Linux 软件进行加密,该软件驻留在 /boot 中的 initramfs 上,并相应地提示用户。