挂起与恢复之间“密码设置luksOpen <根device>”的数据丢失安全性

Question

我正在设置挂起到磁盘，并继续在一个2021.12.xArchLinux安装。我的问题是在恢复时安全地(不丢失数据)解锁分区。

这是我的配置。引导程序是grub 2.06，我使用的是一个基于busybox的initramfs。相关分区如下。我不使用LVM。

# partition  encrypted   mountpoint     decrypted volume name
- ---------  ---------   ----------     ---------------------
...
3 root           luks2   /              cryptroot
4 swap           luks2   [SWAP]         cryptswap
...

在/etc/mkinitcpio.conf中，我配置了这些钩子。

HOOKS=(base udev ... openswap openroot ... resume ... filesystems fsck)

我不使用内置的加密钩子。它只能解锁一个设备(通常只有在cryptdevice内核参数中指定的根设备)，但我也需要解锁加密的交换设备。因此，我不使用加密钩子，而是使用两个自定义钩子: openswap和openroot。从本质上讲，openswap钩子运行：cryptsetup luksOpen cryptswap，它提示输入密码。openroot钩子对根分区设备cryptsetup luksOpen cryptroot也这样做。

接下来，内置的简历挂钩将交换设备的主要和次要数字写入/sys/power/resume。

printf "$devmajor:$devminor" >/sys/power/resume

目前有两种情况。

场景1:如果在完全关闭后启动，

在完全关机后启动计算机时，未锁定的交换分区中没有休眠映像。没有什么可恢复的，所以会进行定期的引导。根分区已被解锁(通过openroot钩子)，因此引导可以正确进行。

在这种情况下不存在安全问题。

场景2:如果在挂起到磁盘

之后启动

更早的时候，当我启动挂起到磁盘时，根分区将处于未锁定和挂载状态，而休眠映像将按原样捕获此状态。现在，在内核使用这个休眠映像恢复之后，系统将继续使用这个(已经)解锁/挂载的根分区设备。

This是我提出问题的地方：

我知道在暂停和恢复之间使用mount是不好的。例如，kernel.org说：“如果您在挂起和恢复……之间触摸到磁盘上的任何内容，请与您的数据吻别。”我的配置不是这么做的。

在挂起和恢复之间的设备cryptsetup luksOpen也同样不好吗？cryptsetup luksOpen是否构成了磁盘的触摸(kernel.org术语)？回想一下，initramfs openroot钩子在挂起和恢复之间运行cryptsetup luksOpen cryptroot。

如果是的话，如何处理呢？

Answer 1

cryptsetup luksOpen本身就是一个纯粹的只读操作.但是，只需解锁块设备，就会触发依赖项(例如udev规则)，而这又可能触发自动组装(对于raid和lvm设备)，从而创建更多的块设备，进而触发更多的udev规则等等。

因此，最好通过正确的顺序运行钩子来避免整个难题。

如果resume钩子只需要交换分区(即不涉及其他交换设备或交换文件)，resume应该在openswap之后直接运行，在openroot之前运行。

否则，您的设置也会产生错误的安全性，方法是请求一个根本不需要的根加密密码，并且无论如何都会被简历丢弃。

除非您有要停止执行的代码，否则对于挂起的系统，即使您多次为resume钩子输入错误的密码短语，openroot钩子也会成功。因此，在改变钩子顺序之前，这是一个简单的方法来验证这个理论。