这是 ecryptfs 开发人员解释 ecryptfs 和 dm-crypt 之间区别的页面:https://stackoverflow.com/questions/18230784/linux-kernel-subsystem-dm-crypt-and-ecryptfs 之间有什么区别/18234635#18234635。但是,这让我有一个疑问,如果 ecryptfs 仅加密/home
分区,那么如何阻止恶意黑客修改/
或/boot
分区以嗅探加密密码或修改程序等......
简而言之,我如何确保我的计算机数据不仅不会被未经授权的人员读取,而且还如何确保我的计算机上的任何内容不会在我不知情的情况下被修改?
此外,这一切到哪里结束呢?因为在某个时候,引导代码必须解密,处理器才能理解它?(除非你使用某种硬件解密)但根据定义,任何未加密的东西都可以修改?
(顺便说一句,我可以看到一种确定引导序列完整性的方法,即在加密部分中保存引导代码未加密部分的哈希值,并在解密时将预先计算的哈希值与运行时引导序列未加密部分的哈希值进行比较。但是,这并不能解决存在未加密区域的问题,只是事后知道是否修改了某些内容的一种方法)
答案1
简短的回答是“很少”能够阻止黑客修改 /boot - 实际上只有时间、未被发现的物理访问和使用键盘记录器重新编译 initrd 的能力。
如果恶意黑客拥有物理系统访问权限,则没有什么可以阻止他们修改基于 ecryptfs 的 / 或 /boot - 但稍后再看 - 这不是本文的目的。
“/” 可以使用 LUKS 等全盘加密进行保护(但据我所知,不能使用文件加密)- 由于系统最初从 /boot 启动,因此 initrd 可以在挂载 / 之前请求解锁卷所需的密码
我认为您高估了全盘加密的能力 - 我认为它旨在保护人们免受非持续性威胁,例如笔记本电脑被盗,或者当您想要 RMA 包含个人信息的硬盘时 - 在这两种情况下,数据对您不再有用,但您想阻止未知的第三方访问它 - 并且,很多时候,基于文件的文档加密就足够了 - 谁在乎他们是否有系统二进制文件的未加密副本 - 无论如何它们都是开源的。
您无法保护您的系统免受未经授权的本地访问人员的侵害 - 因此解决方案是防止物理访问。您可以通过对所有系统文件进行校验并与离线备份进行比较来确保内容不会在您不知情的情况下被修改 - 这不是万无一失的,因为您需要确保您正在运行未修改的校验和程序 - 并且该程序使冲突哈希几乎不可能重新创建。[如果您将文件系统分开并使其中一些文件系统为只读,然后为每个只读分区保留一个哈希,您可能会简化此过程]。但是整个过程很麻烦。
当使用全盘加密“/”时,您通常不会将计算机用作“root”,除非升级等 - 这提供了相当程度的