☰

更改实时挂载的 ecryptfs 卷的底层加密文件是否安全？

tag-icon • tag-icon linux encryption synchronization ecryptfs
更改实时挂载的 ecryptfs 卷的底层加密文件是否安全？

我想与服务器进行加密目录的实时同步，以便服务器只能看到加密数据。

假设我将底层 ecryptfs 数据放入：

/home/user/.Private

我将该目录挂载到：

/home/user/unlocked

我可以更新文件.Private（例如使用 rsync）并期望unlocked反映更改吗？还是这只会把事情搞砸？有没有更好的加密数据实时同步替代方案？

更新澄清：

我只想将加密数据传输到服务器——服务器不受信任。所以我想看到：

 client <-- encrypted data --> server

可能有多个客户端更新（解密）文件；因此需要实时同步：

 client1
        \
         \--- encrypted data --\
                                \
                                 server
                                /
         /--- encrypted data --/
        /
 client2

因此客户端有一个包含加密文件的目录——按照 ecryptfs 的方式分块：

/home/client1/.Private/
                 |--- ECRYPTFS_FNEK_ENCRYPTED.Fabcde.../
                 |                                    |--- ECRYPTFS_FNEK_...
                 |
                 |--- ECRYPTFS_FNEK_ENCRYPTED.Flaksd.../
                                                      |--- ...

这是用 ecryptfs 安装的：

/home/client1/unlocked/
                 |--- secret_file_1
                 |--- secret_file_2

现在，客户端 1 正忙于更改 中的文件unlocked。当客户端进行更改时， 中的底层加密文件也会.Private更改。因此，本地 inotify 或类似程序会注意到更改，并将加密的基本文件 rsync 到.Private服务器中。服务器知道客户端 2 也在监听，因此通知客户端 2 它应该提取更改。

所以我担心的是：如果客户端 2 在 中安装时将底层 encryptfs 分块文件拉入 .Private unlocked，我怀疑这会导致问题，不是吗？这将要求客户端 2 在同步之前卸载unlocked，这破坏了整个“实时同步”的想法。

如果是这样，那么有哪些好的替代技术可以有效同步加密树的差异？

答案1

根据 Tyler Hicks（eCryptfs 的维护者之一）的说法，目前修改底层文件系统（eCryptfs 术语中的下层文件系统）是不安全的：

如果 eCryptfs 可以检测到较低的文件数据变化并更新缓存以查看文件更新，那就太好了。

即使我们能检测到它们，我们如何才能防止它们感染 eCryptfs 脏页？我们如何知道哪些是最新的数据？

不幸的是，直接修改底层文件系统不受支持。如果修改不通过 eCryptfs 挂载点，由于 eCryptfs 架构，我们不可能知道它。

来源：https://bugs.launchpad.net/bugs/689030

答案2

要更新 ecryptfs 文件系统中的文件，您需要在挂载点更新它们 - 在加密文件系统中，您需要一次更新整个文件，因为它没有文件或目录的概念 - 它只是一大块数据。

是的，您可以使用 rsync 将数据备份到某处，但是为了读取或写入特定文件，您需要挂载它。

您可以从不同的地方挂载它（最好不要同时尝试:-) 那么为什么不使用一个 shell 脚本来挂载、rsync 相关文件并在相关文件更新时卸载呢？

有用的信息这里

相关内容