Darren J Moffat wrote: > Anthony Scarpino wrote (elsewhere): >> While writing up the man page.. I thought of a few things that I was >> wondering if you considered.. >> >> Can an encrypted dataset (keytype=dataset) reside in a non-encrypted (no >> kek defined) pool? > > I can see a case for and against allowing this when considering it > purely at the feature level as users/admins see things. > > The admin can control wither users can enable encryption or not by > delegating (or not) the "encryption" and "keytype" properties. So there > is no need to use the pool wrapping key (ie require the kek to be > available) to restrict creation of encrytped datasets. > > If the admin doesn't want encryption in any dataset delegated to a user > then don't delegate those properties and ensure they are inherited as > encryption=off. >
Depending on 6647661 (setting pool level dataset properties at creation), delegation may be the only control as encryption can't be set post-creation. > > We need to be able to provide key change for keytype=dataset as well. > That means that the actual encryption key for the dataset needs to be > done the same way as keytype=pool, ie it is a wrapped key that is stored > in the "wrappedkey" property not the actual encryption key. Regardless > of the need for key change the encryption key needs to be generated > while the dataset is being created; and for the filesystem case it needs > to happen before the root directory of the filesystem is created - > leaving it unmounted isn't actually enough. > > So this means that we have an ordering problem for the initial key > setup. We need the per dataset wrapping key to wrap the new randomly > generated dataset encryption key while we are creating the dataset. That > assumes that 'zfs key -l' has been run, but we can't do that because the > dataset doesn't exist yet. > > We also worked out that this could be tricky for the cli, because it > seems to imply a three step process that isn't atomic - and this I think > is a bad model. > Why can't we just hold off dataset key generation for keytype=dataset until the 'zfs key -l" command? We will know from the kek_check that it's unset and the zfs command will know from the keytype to not do the keygen/wrapping operations yet like it would do for keytype=pool? > Example 1: > > 1$ zfs create -o encryption=on tank/foo > > At this point we have a randomly generated encryption key wrapped by the > pool key. > > 2$ zfs set keytype=dataset tank/foo > > The property gets changed but we can't re-wrap the encryption key > because we don't have the new per dataset wrapping key. > > 3$ zfs key -l tank/foo > Enter new passphrase: > Re-Enter passphrase: > 4$ zfs mount tank/foo > > Here 'zfs key -l' "defines" the dataset key and does an unwrap using the > pool key (which had to have been present or step 1 would have failed) > and a (re)wrap using the newly defined dataset key. > > [ Note that there is a per dataset property for choosing what type of > key we are using - passphrase or file in phase 1 with pkcs11 coming in > 1.1, I'm just using passphrase for the examples in this discussion ]. > > > That could be a problem since step 2 without step 3 leaves the dataset > in a possibly unusable configuration. However we do know that the per > dataset key hasn't actually be loaded yet (because the hidden per > dataset property key_check would be undefined). The big concern I have > with this is how it looks to the user/admin when looking at the > properties and the steps they have to take. After step 2 but before step > 3 they would likely see: > > encryption=on > keytype=dataset > kek=passphrase > keystatus=undefined > > Example 2: > > A similar case with the same issue is this one: > > 1$ zfs create -o encryption=on -o keytype=dataset tank/foo > 2$ zfs key -l tank/foo > Enter new passphrase: > Re-Enter passphrase: > 3$ zfs mount tank/foo > > > Some discussion that Tony and I had recently I think we came to the > conclusion that what it might be better done like this: > > Example 3: > > 1$ zfs create -o encryption=on tank/foo > > At this point we have a randomly generated encryption key wrapped by the > pool key. > > 2$ zfs key -c -o keytype=dataset tank/foo > Enter new passphrase: > Re-Enter passphrase: > 3$ zfs mount tank/foo > > We change the property, define the new per dataset wrapping key and > re-wrap the dataset key and store it on disk using the new per dataset > wrapping key, all as part of that single action. > > Note here that the passphrase is the new one for the dataset not the > pool passphrase. > > This makes keytype a "strange" property because it means it can only be > changed by 'zfs key' and can't be set at create time to anything except > 'pool' (and then only if the pool wrapping key is present) - which could > be an issue for property inheritance. > > > Does anyone have an alternate proposal ? [ please don't nitpick on the > property names at this time what I want discussed is the semantics not > the syntax ]. >
