[Bug 1857398] Re: ubiquity should support encryption by default with zfsroot, with users able to opt in to running change-key after install

[Didier Roche]

Thanks Richard for digging in, the performance comparison and the valuable upstream feedback and pointers.
Good catch about retrieving the master key written in old blocks with the previous (fix) passphrase even if changed later on. It seems that trimming could help. Do you think that we should base on work going that direction (overwriting old keys) and keep the current approach?

On a more general side, the approach seems to be forward-compatible with
per user dataset encryption (zfs change-key <dataset>), which creates a
new encryption root.

Steve:
* the only comment I have on the ubiquity part of the equation is based on Richard's feedback. Otherwise, looks good to me. I think we should wait on the above feedback before taking a finale decision on the approach though.
* the zfs-linux initramfs POC looks good (not tested though, currently travelling, but I didn't spot any issues). It should be easily pluggable later on once the user set it to "prompt" with their own passphrase and use the plymouth prompt codepath. (Not tested yet either).
Just a nitpick: Colin asked for our patches in zfs-linux to be numbered (hence the 4XXX- namespace), as the debian ones. It seems that it's not reliably the case since the 0.8.2 merge with debian, so need double checking (order seems as well messy after this merge right now).

Anyway, we need to wait on the kernel patches first.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1857398

Title:
  ubiquity should support encryption by default with zfsroot, with users
  able to opt in to running change-key after install

Status in ubiquity package in Ubuntu:
  New
Status in zfs-linux package in Ubuntu:
  New

Bug description:
  zfs supports built-in encryption support, but the decision of whether
  a pool is encrypted or not must be made at pool creation time; it is
  possible to add encrypted datasets on top of an unencrypted pool but
  it is not possible to do an online change of a dataset (or a whole
  pool) to toggle encryption.

  We should therefore always install with encryption enabled on zfs
  systems, with a non-secret key by default, and allow the user to use
  'zfs change-key -o keylocation=prompt' after install to take ownership
  of the encryption and upgrade the security.

  This is also the simplest way to allow users to avoid having to choose
  between the security of full-disk encryption, and the advanced
  filesystem features of zfs since it requires no additional UX work in
  ubiquity.

  We should make sure that
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1857040 is fixed
  first in the kernel so that enabling zfs encryption does not impose an
  unreasonable performance penalty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1857398/+subscriptions