> It is not appropriate to require the user to type a password on every
> boot by default; this must be opt-in.
Agreed.
The installer should prompt (with a checkbox) for whether the user wants
encryption. It should default to off. If the user selects the checkbox,
prompt them for a passphrase. Setup encryption using that passphrase.
This is exactly how the installer behaves today for non-ZFS (e.g. using
LUKS). I'm proposing to extend that existing behavior to ZFS. Thi should
be trivial to implement; I'm not sure if we still have time for 20.04,
but I'd really love to see at least this much implemented now.
What should happen if the user leaves the encryption box unchecked?
Currently, they get no encryption, and that's what I'm proposing
initially. You'd like to improve that so that the user can later set a
passphrase without having to reformat their disk. I agree that's a
reasonable goal.
I think the blockers / potential blockers are:
1) `zfs change-key` does not overwrite the old wrapped master key on
disk, so it is accessible to forensic analysis. Given that the old
wrapping key is a known passphrase ("ubuntuzfs"), another way of looking
at this is that the master key is still on disk in what is, security-
wise, effectively plaintext. I (and other upstream ZFS developers) are
concerned about giving the user a false sense of security in this
situation. ZFS could overwrite the key on disk when changed. If/when
someone adds that enhancement to `zfs change-key`, then I think this
objection goes away. I don't see this being implemented in time for
20.04.
2) Is the performance acceptable? On older systems without AES-NI, there
is a noticeable impact, which I've seen myself. I recommended using AES-
NI support as the deciding factor here... if they have AES-NI, then
encrypt (with a known passphrase) even if the user didn't opt-in; if
they don't have AES-NI, then not opting-in means encryption is really
off. If that inconsistency is a problem, then ultimately Ubuntu just has
to decide one way or the other. Personally, I'm a big fan of encryption,
so I'm not going to be upset if the decision is that the performance
impact on older hardware is just something to accept.
> > I would recommend setting encryption=aes256-gcm instead of
> > encryption=on (which is aes256-ccm).
>
> I think the right way to handle this is to change the behavior of
> zfs-linux so that encryption=on defaults to the recommended algorithm -
Agreed. I proposed this at the last OpenZFS Leadership meeting and there
is general agreement to do so. It does need a bit more discussion and
then implementation (which should be trivial).
> rather than hard-coding the algorithm selection in ubiquity, which is
> generally speaking a good recipe for bit rot.
Given that I'd like to see encryption land in 20.04, I think it would be
reasonable to set -o encryption=aes-256-gcm today and then change it
(e.g. for 20.10) to "on" once the default changes in OpenZFS.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux 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
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
