On Tue, Sep 13, 2022 at 6:21 AM Anand Jain <anand.jain@xxxxxxxxxx> wrote: > > On 06/09/2022 08:35, Sweet Tea Dorminy wrote: > > From: Omar Sandoval <osandov@xxxxxxxxxxx> > > > > Creating several new subvolumes out of snapshots of another subvolume, > > each for a different VM's storage, is a important usecase for btrfs. > > > We > > would like to give each VM a unique encryption key to use for new writes > > to its subvolume, so that secure deletion of the VM's data is as simple > > as securely deleting the key; to avoid needing multiple keys in each VM, > > we envision the initial subvolume being unencrypted. > > In this usecase, you didn't mention if the original subvolume is > encrypted, assuming it is not, so this usecase is the same as mentioned > in the design document. Now, in this usecase, what happens if the > original subvolume is encrypted? Can we still avoid the multiple keys? > How is that going to work? Or we don't yet support subvolumes out of > snapshots of another encrypted subvolume? > Count this as the first official "email triggered by Plumbers" I suppose, but I've been looking forward to Btrfs encryption for Fedora for a variety of use-cases: * Converting a disk from unencrypted to encrypted without reinstalling[1] * Encrypting system and user data with different credentials[2][3] * Mass managed systems with dual-credential encryption (one rooted in org, other by user)[1] The way I envision Fedora's usage of this feature going is as follows: The system is shipped (OEM install; e.g. Lenovo, Slimbook, etc.) or installed without encryption (from Anaconda). The firstboot process helps the user get setup, and asks if they want disk encryption (provided there is no policy forcing it on). If the answer is yes, then the root subvolume and the home subvolume are configured to be encrypted using the on-board secure enclave (TPM or whatever). When the user creation step occurs, if disk encryption was set on earlier, then the user subvolume inside the home subvolume gets configured to be encrypted using the login credentials. If it wasn't set on earlier, we could also still offer to encrypt the user data here. If this is a mass-managed system, an additional decryption key would be available for the system manager to use in the event of credential loss, damaged TPM, etc. For the cloudy scenario, we'd probably provide tools to orchestrate this from cloud-init for confidential computing stuff too. For all this to work, I expect the following: * Encryption to support *somehow* any number of decryption keys/methods * Nesting of subvolumes with differing encryption methods * The ability to blindly backup and restore subvolumes without needing to decrypt On a personal system, I expect at most two credentials in use: one keyed to the system and one keyed to the user. For a corporate/mass managed system, I expect a third one: one keyed to the management platform. This is necessary because in a lot of jurisdictions, you don't necessarily own the data on your corporate laptop, and the owner has the right to be able to access that data. But a more prosaic or banal reason is that people forget their credentials and being able to reset them without losing all their data is usually a good thing. :) Hopefully I've transcribed what I said properly into this email. :) [1]: https://pagure.io/fedora-btrfs/project/issue/10 [2]: https://pagure.io/fedora-workstation/issue/82 [3]: https://pagure.io/fedora-workstation/issue/136 -- Neal Gompa (FAS: ngompa)
|