Re: [PATCH v2 02/20] fscrypt: add flag allowing partially-encrypted directories

From: Neal Gompa <ngompa@fedoraproject.org>
To: Anand Jain <anand.jain@oracle.com>
Cc: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	Eric Biggers <ebiggers@kernel.org>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org,
	kernel-team@fb.com, Omar Sandoval <osandov@osandov.com>,
	Chris Murphy <lists@colorremedies.com>
Subject: Re: [PATCH v2 02/20] fscrypt: add flag allowing partially-encrypted directories
Date: Tue, 13 Sep 2022 07:02:45 -0400	[thread overview]
Message-ID: <CAEg-Je_=K6ky95ybv=Dx21bUPWjP-Vew14pu4KWVDQuYn+NTNg@mail.gmail.com> (raw)
In-Reply-To: <dbb3a5ea-65d9-12bd-bde3-e16ab2f44adc@oracle.com>

On Tue, Sep 13, 2022 at 6:21 AM Anand Jain <anand.jain@oracle.com> wrote:
>
> On 06/09/2022 08:35, Sweet Tea Dorminy wrote:
> > From: Omar Sandoval <osandov@osandov.com>
> >
> > 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)