> 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 Ubuntu
Bugs, which is subscribed to 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1857398/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
