On Fri, Sep 16, 2016 at 06:49:53AM +0000, Alex Elsayed wrote: > The main issue I see is that subvolumes as btrfs has them _do_ introduce > novel concerns - in particular, how should snapshots interact with keying > (and nonces)? None of the AEADs currently in the kernel are nonce-misuse > resistant, which means that if different data is encrypted under the same > key and nonce, things go _very_ badly wrong. With writable snapshots, I'd > consider that a nontrivial risk.
Snapshots should copy subvolume keys (or key UUIDs, since the keys aren't stored in the filesystem), i.e. an ioctl could say "create a new subvol 'foo' with the same key as existing subvol 'bar'". This could also handle nested subvols (child copies key of parent) if the nested subvols weren't created with their own separate keys. For snapshots, we wouldn't even ask--the snapshot and its origin subvol would share a key unconditionally. (*) I don't see how snapshots could work, writable or otherwise, without separating the key identity from the subvol identity and having a many-to-one relationship between subvols and keys. The extents in each subvol would be shared, and they'd be encrypted with a single secret, so there's not really another way to do this. If the key is immutable (which it probably is, given that it's used to encrypt at the extent level, and extents are (mostly) immutable) then just giving each subvol a copy of the key ID is sufficient. (*) OK, we could ask, but if the answer was "no, please do not use the origin subvol's key", then btrfs would return EINVAL and not create the snapshot, since there would be no way to read any data contained within it without the key. > > Indeed, with the generic file encryption, btrfs may not even need the > > special subvolume encryption pixies. i.e. you can effectively implement > > subvolume encryption via configuration of a multi-user encryption key > > for each subvolume and apply it to the subvolume tree root at creation > > time. Then only users with permission to unlock the subvolume key can > > access it. Life is pretty easy when we're only encrypting data extents. Encrypted subvol trees cause quite a few problems for btrfs when it needs to relocate extents (e.g. to shrink a filesystem or change RAID profile) or validate data integrity. Ideally it would still be able to do these operations without decrypting the data; otherwise, there are bad cases, e.g. if a disk fails, all of the subvolumes would have to be unlocked in order to replace a disk. Still, there could be a half way point here. If btrfs could tie block groups to subvol encryption keys, it could arrange for all of the extents in a metadata block group to use the same encryption key. Then it would be possible to relocate the entire metadata block group without decrypting its contents. It would only be necessary to copy the block group's encrypted data, then update the virtual-to-physical address mappings in the chunk tree. Something would have to be done about checksums during the copy but that's a larger question (are there two sets of checksums, one authenticated for the encrypted data, and the crc32 check for device-level data corruption?). There's also a nasty problem with the extent tree--there's only one per filesystem, it's shared between all subvols and block groups, and every extent in that tree has back references to the (possibly encrypted) subvol trees. I'll leave that problem as an exercise for other readers. ;)
signature.asc
Description: Digital signature
