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.....

[etr06]

@qdm12 did you get this working? I was working on my own simple script to do this, but was waiting to see how yours turned out.

[qdm12]

Hi there, sorry for disappearing for some time. I actually need this script right now, lucky you! So I will probably finish it today.

[qdm12]

So I pushed what I was working on more or less, in one commit. I'm working on it now, feel free to help or suggest anything 👍 I will likely finish it tomorrow though. Thanks!

[etr06]

Thanks for your work so far! Looks better than what I have done.
I do have one suggestion when you are creating encrypted datasets.

In case of user supplied password mismatch in my script I just made the command loop until it completes successfully. That way the script won't just drop you to the terminal on a password mismatch.

echo "Creating datasets..."
while :
do zfs create -o mountpoint=none "${zfsoptions}" "${zroot}"/ROOT || {
        break
    }
    true
done

while :
do zfs create -o mountpoint=none "${zfsoptions}" "${zroot}"/data || {
        break
    }
    true
done

But maybe the better way is to store the password in a variable and pass it to keylocation=prompt somehow?

[johnramsden]

@qdm12 Looking good so far. If you want to open a PR and mark it as WIP, keeping us up-to-date on how things are going it might be a better place than an issue for feedback, especially since it supports easily reviewing code.

I haven't played with native encryption myself, so I don't really know what happens on boot. Do you end up having to put in your password when the pool is mounted? Does integration need to be done at the bootloader level?

[qdm12]

@johnramsden agreed, I'll open the PR asap as I unfortunately didn't have time to finish it today, I'm hitting the joy of shell scripting for loops 😆

We can then discuss on the PR as you mentioned. @etr06 good idea with the loop 👍

[ec1oud]

What I would like is not to bother with encryption on the whole system, but rather create a separate dataset for each user's home directory (although there's only one user on my laptop), AND have it unlock automatically when I log in, by using the same password to unlock the dataset.

[dagaz]

What I would like is not to bother with encryption on the whole system, but rather create a separate dataset for each user's home directory (although there's only one user on my laptop), AND have it unlock automatically when I log in, by using the same password to unlock the dataset.

I for myself am very interested in whole system encryption. (As far as I am concerned I would also be fine with the pool within an dmcrypt container to conceal even more of the system.) Especially when you use it with a portable system it seems more responsible to encrypt just everything. (Also I assume that everything would be much easier.)

I think per-user-dataset-encryption would be more something for an admin tool/script used when adding users - and for adjusting a session manager.

[Amplificator]

Any progress on this? Alez would be perfect if native encryption was added :)

[markstos]

@ec1oud What you are describing sounds like systemd-homed.