写入/root/工作区不会破坏加密分区内的文件

Question

我在我的硬盘上做了完全的磁盘加密，与本指南完全相同。

https://web.archive.org/web/20180428191153/http://thesimplecomputer.info/full-disk-encryption-with-ubuntu

分区表: GPT

选项：cryptsetup luksFormat --cipher serpent-xts-plain64 --key-size 512 --hash sha512

我有4个加密分区:根分区、交换分区、主分区、工作区和未加密的BIOS引导。在启动时，当我键入我的密码和当我在操作系统中，所有4个分区被挂载和解锁。所有分区都有相同的密码。

出于好奇，我通过ubuntu磁盘应用程序锁定和卸载分区“工作区”，内容消失了，当从Nautilus观看时，它变成了一个空分区。之后，我在里面写了一个简单的文本文件，里面有一些随意的单词。我打开gedit GUI，在里面写了一些文本，然后在锁定的分区中将文件保存为New文本文件。更准确地说，在我从ubuntu中的磁盘卸载并锁定分区之后。我打开Nautilus并导航到/root/workspace。它显示为空，我右击并按Createnew文本文件，然后用Gedit打开，在里面写了一些保存和关闭的东西。然后回到磁盘中，我解锁、挂载和写入我的密码，然后再通过nautilus导航到/root/workspace，我看到我的加密文件都正常工作。

然后我挂上并解锁了分区，里面的文件又出现了，所有文件都正常工作，没有损坏。在此之后，我在加密的分区中编写了大约10 GB的文件(只需复制、粘贴已存在于此分区中的几个不同名称的文件)，然后卸载并再次锁定它。令我惊讶的是，文本文件仍然在那里，它没有被破坏，并且包含相同的单词，没有被碰过。

现在我对这个场景的问题

1. 这是否在某种程度上破坏了FDE，并为攻击创造了新的表面？由于我的根、交换和家庭被挂载，我在清晰的内部卷工作区中写到，这在某种程度上破坏了这一点，并可能导致泄露密码，在其他分区中也使用了？
2. 就我的red头在每个分区的开头而言，当我在未挂载的锁定分区中编写一个文件时，它怎么没有损坏呢？该文件是否应覆盖加密文件中的Luks头或部分？相反，所有的文件都完好无损，我可以重新挂载和解锁。
3. 反之亦然。当我在未锁定和挂载的分区中写入10 of的文件时，它们不应该覆盖该未加密的文本文件吗？相反，当我锁定并卸载它时，使用字符串的文件就完好无损了。
4. 我使用的指南是正确的，还是有些东西没有提到，在某种程度上使我易受伤害？

Answer 1

当您“解锁”加密卷时，它实际上做了两件事：

1. 此加密卷的内容可作为块装置提供给系统。将块设备想象为磁盘或分区，可能是虚拟的。
2. 这个虚拟磁盘恰好包含一个文件系统，文件系统是目录/root/workspace的已挂载。“安装安装的意思是文件系统在该目录下可见。。

您解锁加密卷，然后将文件写入/root/workspace。在编写此文件时，/root/workspace是根分区上的一个普通目录，它没有任何挂载。所以你只是写了一个文件到根分区。它不影响加密卷，因为/root/workspace和加密卷之间没有关系。

当您将加密的文件系统安装到/root/workspace时，这个隐藏了这个目录中的文件。它没有删除文件，只是暂时无法访问。

如果您想要覆盖加密的卷，则必须直接访问它。您不能从Gedit直接执行此操作，因为它只能写入文件系统，不能直接写入磁盘或分区。您可以从命令行使用类似于echo BREAK IT >/dev/sda99的内容(sda99只是一个例子)。您需要以根用户的身份运行它，并找到正确的名称来放置而不是sda99。findmnt的输出包含正确的名称。显然，您在这里应该非常小心，因为如果您这样做，它将破坏您的加密卷，如果您使用错误的卷，它很可能使该卷不可用。

在配置良好的系统上，您不应该能够写入指定为系统挂载点的目录：/root/workspace只应由根用户写入，而不应作为根用户。(请注意，只有当目录上没有挂载时，/root/workspace上的权限才重要:挂载隐藏了目录的内容，包括目录本身。)这样，就不会有意外地将某些内容保存在与您想要的分区不同的位置上的风险:您将得到一个“拒绝权限”错误。要修复/root/workspace上的分区，可以在未挂载/root/workspace时使用以下命令：

sudo chmod 755 /root/workspace; sudo chown root:root /root/workspace

顺便说一句，对于安装点来说，/root是一个非常不寻常的地方。对于临时挂载的卷来说，/media/workspace更常见，对于一直挂载的卷，无论是/media/workspace还是/workspace，或者只是使其成为/home。

同样值得注意的是，如果您已经无法跟踪某个文件是否位于not加密卷上，那么您可以从命令行中看出这一点。( Nautilus中肯定也有一种方式，甚至在Gnome文件打开对话框中也是如此，但我对此并不熟悉。)

df /path/to/file
findmnt

df命令显示包含/path/to/file - df的卷上有多少磁盘空间是空闲的，表示“磁盘空闲”。它还显示卷名及其挂载点。取决于您的卷组织，这可能足以说明。如果不是，查找findmnt输出中的卷，看看它是否是加密卷的子卷。