Arch Linux: Nest system datasets; LUKS bpool; secure boot

[ghost]

• Tell readers that encryption can not be enabled later pool-wide
• Add some warning messages for choosing a strong password
• Remove remains of default-key

@rlaager

Signed-off-by: Maurice Zhou ja@apvc.uk

[ghost]

Actually I think enabling encryption on the pool dataset rpool is quite inflexible. The only way to get rid of the encryption or change any readonly dataset property is to destroy and rebuild the pool. A number of commands, such as zfs rename, can not be used on the pool dataset.

If we store everything under a child dataset, say rpool/arch, only enable encryption on this dataset. Then disable encryption, or rebuild system after password leak, could a relatively simple prcedure.

This also allows multi-distro, each with their own encryption password at boot:

rpool/arch/...
rpool/artix/...
rpool/debian/...
EFI/arch/grubx64.efi
EFI/artix/grubx64.efi
EFI/debian/grubx64.efi

Maybe this is the way forward?

[ghost]

Worked out the changes. Datasets are nested under pool/sys.

Can be renamed online with zfs rename -u. A GRUB reinstall should suffice. zfs-list.cache is updated by zed.

As stated above. If one want to enable/disable encryption, just follow the guide to recreate datasets, and copy things over. No zpool destroy needed.

[rlaager]

Actually I think enabling encryption on the pool dataset rpool is quite inflexible. The only way to get rid of the encryption or change any readonly dataset property is to destroy and rebuild the pool. A number of commands, such as zfs rename, can not be used on the pool dataset.

Right, those are the downsides.

Some advantages of making the top-level dataset the encryption root are:

1. Everything can be encrypted at once: "OS" datasets like rpool/ROOT/ubuntu_UUID (and its children), OS-managed home directory datasets like rpool/USERDATA/username_UUID, and administrator-managed datasets like rpool/srv (or whatever). Obviously, some bits of that layout are zsys-specific, but the general concepts predate zsys (e.g. see the Debian Buster HOWTO).
2. This is conceptually similar to "full disk encryption", so it fits into existing designs (e.g. installers) easily.
3. It avoids the need for an intermediate dataset level (in your case, you used rpool/sys), which is: A) just nicer, B) backwards compatible with existing installs, and C) consistent between encrypted and unencrypted setups. That said, consistency can be maintained by having the additional dataset level in both encrypted and unencrypted setups, which I think is what you have done.

If we store everything under a child dataset, say rpool/arch, only enable encryption on this dataset. Then disable encryption, or rebuild system after password leak, could a relatively simple prcedure.

Disabling encryption is perfectly fine. But if you want to enable encryption or change the key, there's no great way to guarantee that the old data is off the disk. Granted, with SSDs and TRIM, it's pretty close. And there is a trade-off: if we want to make an absolute guarantee, then the answer is "wipe the disk and rebuild your pool", but that's not great for e.g. individual desktop users, and getting them something good might be better than nothing.

Personally, I don't think that encrypted -> unencrypted is a transition that people generally are about these days. The other direction (enabling encryption) is probably more common. But that said, I personally don't see a lot of value in being able to transition. One should just do it right on the install the first time. ;)

This also allows multi-distro, each with their own encryption password at boot:

rpool/arch/...
rpool/artix/...
rpool/debian/...

It allows for that yes. It also more-or-less requires it. While the passphrases can be manually set to be the same, they're not the same encryption root. If that is what someone wants, it's a feature. If that is not what someone wants, it's a "bug" (not really, but the user won't love it). So this cuts both ways.

[ghost]

Regarding multi-distro:

While the passphrases can be manually set to be the same, they're not the same encryption root.

If one wants to enable encryption for all distros, with the same passphrase, then yes, she has to manually set the same passphrase, this is supported.

Disabling encryption or setting different passphrases is also supported, thus more flexible than shared encroot.

Of course, not sharing the same encroot also means that the master key is not shared, so more secure than shared encroot.

[ghost]

Scrolling LUKS faq:

On the other hand, an initrd is about as vulnerable to a competent attacker as a non-encrypted root, so there really is no security advantage to doing it that way. An attacker that wants to compromise your system will just compromise the initrd or the kernel itself.

So unencrypted boot pool is a security risk, especially on a system with encrypted root pool. For real security, it's either encrypt everything or nothing.

initrd can be trivially modified to intercept and transfer root pool passphrase. initrd, in unencrypted boot pool, is world-writable by everyone who has physical access to the computer.

The only way to mitigate this issue is to use GRUB and encrypt boot pool with LUKS.

[rlaager]

initrd can be trivially modified to intercept and transfer root pool passphrase.

Two things to remember about security are: 1) What is your threat model? 2) There are always trade-offs.

I'm personally less worried about a motivated attacker trojaning my initrd to capture my passphrase. I'm primarily trying to protect the data at rest. That is, if someone steals my laptop, the data is protected. The thief is far more likely to be stealing my laptop out of a desire for the laptop, not the data. But keeping the data encrypted at rest means I don't need to worry so much about the data being compromised.

There are other environments with other threat models. If I've got Top Secret national security data on my laptop, the threat model is likely very different. But I'm not trying to target that high of a threat model / security environment (nor am I likely competent to do so by myself).

It is certainly possible to do the unlocking with GRUB, using a LUKS-encrypted boot partition of some kind. Then, inside that LUKS-encrypted boot partition, you can store a keyfile which is used to unlock the root filesystem/pool. I even implemented that once in the Ubuntu HOWTO. But I eventually dropped that because a key design goal of mine is to follow the distro (Ubuntu in that case) as closely as possible. I'm trying to make ZFS an option, not second-guess all the distro design decisions. Ubuntu uses an unencrypted initrd and has the initrd (not GRUB) prompt for the passphrase, so that's what I did. Following the distro is less jarring for users; they are presumably happy with their distro choice and just want ZFS. It also makes it far easier and thus far more likely that ZFS support can be integrated into the distro and/or its installer.

I encourage you to follow whatever Arch is doing for non-ZFS full-disk encryption setups. If Arch is doing GRUB unlocking, do that. If Arch is doing initrd unlocking, do that. If you dislike their design decisions, then try to address those in the distro rather than carrying large deltas in the ZFS HOWTO.

[ghost]

Well I bricked by EliteBook 820 G3 laptop motherboard by using generic tool KeyTool.efi, in a manner similar to this post. Warning messages added.

EDIT: not so completely bricked: screen blank before initramfs, UEFI setup menu broken thus enforcing the enrolled key. Might be fixed with replacing BIOS chip.

[ghost]

I encourage you to follow whatever Arch is doing for non-ZFS full-disk encryption setups.

Arch Linux is a DIY distro, there's no installer, only a minimal installation guide exists as framework. Users are also encouraged to choose their own encryption, as evidenced by docs.

In the same spirit of ArchWiki, optional LUKS bpool is documented in guide.

[ghost]

@rlaager: I'm done with the changes. Please review.