support for encryption?

[pinpox]

Hi,

does ALEZ support encryption?
If so, how do I enable it?

I'm considering renistalling arch and would like to use ZFS but need disk encryption to protect sensitive data in case I loose my notebook.

Thanks for the great script!

[danboid]

It doesn't support encryption yet but I don't see why that couldn't be added.

[qdm12]

Adding native encryption (coming since ZFS 0.8) would be a very nice addition.

For now, maybe is there a way to encrypt the root ZFS volume after running alez?

[johnramsden]

@qdm12 There isn't a way to encrypt an existing dataset, but you could send your dataset to a new encrypted dataset using something similar to what was mentioned in openzfs/zfs#7966 (comment)

zfs send zroot/ROOT/default | zfs recv -o encryption=on zroot/ROOT/encryptedroot

It would then need to change your bootloader and fstab, and reboot into the new dataset. I haven't used native ZFS encryption before, so I'm not sure what else would be involved in setting up the encrypted dataset prior to receiving it, I assume you need to have your keys setup.

[qdm12]

Hi all,

I am almost done changing alez.sh to support ZFS native encryption with passphrase, existing keyfiles (raw or hex) or new generate keyfiles (raw or hex). In my modifications I have also added support for N disks (mirror) and support for raidz1, raidz2 and raidz3 (depending on the number of drives). Now I am working on the boot part, probably the hardest!... I will open a PR soon today or tomorrow.

Also, to save time, can someone explain briefly to me how is the current process to setup the boot partition for UEFI and MBR for both Grub and sytemd-boot? Especially about mirroring these boot partitions for redundancy and eventually encrypt them (but probably not!). Thanks !

[johnramsden]

Sure, this is In regards to #41 then? If so, i'll post it there.

If you want to open up a WIP PR I could also describe things there. Maybe one for the encryption and one for UEFI mirroring.

[danboid]

Hi Quentin!

Thanks for helpng improve ALEZ! Sorry I've not had any time to work on it recently, life has got in the way but I look forward to testing your PRs soon as I get a chance. Hopefully John will get to try them ASAP.

[xunil154]

Hi, I just went through the process of getting ArchLinux with ZFS Root sitting on a LUKS encrypted partition and booting with UEFI.

I tried your ALEZ script, but it didn't work for me, so I put together all my notes into a script. It might be of use to you for flushing this issue through.

https://gist.github.com/xunil154/e7292db25428a26cdfca4d683a9bcb8d

[qdm12]

Thanks!

It's pretty easy to setup with ZFS encryption, I am changing alez.sh these days to support it (with dialog menus etc.). It should be done in the coming days.

[danboid]

Thanks Chris and Quentin!

[sjug]

Thanks!

It's pretty easy to setup with ZFS encryption, I am changing alez.sh these days to support it (with dialog menus etc.). It should be done in the coming days.

@qdm12 Do you have a branch somewhere? Are you using ZFS native encryption?

[qdm12]

I have it locally on an older version of alez.sh, so I'm in the process of moving it to the latest alez.sh now to avoid strange merge conflicts. I will update here once I create a PR. It should add support for single drive, mirror, raidz1, raidz2, raidz3 depending on the number of partitions selected through a dialog checklist (instead of while loop with a menu). And you should have the option to encrypt the whole volume afterwards although I am still in the process of testing everything works ok.

[xunil154]

Thanks!

It's pretty easy to setup with ZFS encryption, I am changing alez.sh these days to support it (with dialog menus etc.). It should be done in the coming days.

While ZFS does now support native encryption, it does not provide metadata protections. i.e. your pool names, dataset names, snapshot names, etc will not be encrypted. If your goal of full disk encryption is to provide protections for plausible deniability, then you can not rely on ZFS encryption alone for that. And unless you take the extra precautions to ensure all datasets are encrypted, any unencrypted datasets will not benefit from those protections (obviously).

Since full disk encryption is typically used to provide defenses against a bad actor with physical access to your devices (i.e. stolen), exposing the minimal amount of information is critical to ensuring the overall security of your data. For example, if I have a system with ZFS as root, with an encrypted root dataset, and I have a snapshot called zpool/root@pre_encrption_08_2019 now the attacker knows which snapshot is potentially unencrypted. Or another simple example could be a dataset named zpool/clients/john.doe, exposing the fact that John Doe was a client, which could be enough information for an attacker to launch a social engineering attack.

This is at least my rationale for why I opted to use ZFS on top of LUKS, as LUKS can provide those protections, and I have the added assurance that all my data is encrypted without the worry of accidental leaks. I can also always layer encryption with encrypted ZFS datasets on top of the LUKS protections, to also provide some run-time protections to data I might not need all the time (e.g. client data) to help protect data in the event my system becomes compromised.

I just wanted to provide some of my insights in case it is useful for anyone.

Now where did my tin foil hat go.....