If trying to unlock a v2-encrypted directory fails because the kernel lacks support for v2 policies, show a better error message. This can happen if someone downgrades their kernel or tries to access encrypted directories on removable storage from a computer with an older kernel. Detecting this case is difficult since all we have to go with is EACCES when opening the directory. Implement a heuristic where if get EACCES, we actually have read access to the directory, and the kernel doesn't support v2 policies, we show the improved error message. Before: # fscrypt unlock dir [ERROR] fscrypt unlock: open dir: permission denied After: # fscrypt unlock dir [ERROR] fscrypt unlock: open dir: permission denied This may be caused by the directory using a v2 encryption policy and the current kernel not supporting it. If indeed the case, then this directory can only be used on kernel v5.4 and later. You can create directories accessible on older kernels by changing policy_version to 1 in /etc/fscrypt.conf.
v2 encryption policies are now recommended, due to various security and usability advantages over v1 policies. Many people have been running into the usability problems with v1, so it's desirable to get people onto v2 without having to manually opt-in. Therefore, when 'fscrypt setup' creates /etc/fscrypt.conf, enable policy_version 2 automatically if the kernel supports it. I decided to go with this solution over the policy_version "auto" I suggested originally because this way is simpler, it can still be changed to "auto" later if desired, and "auto" might require changing how we parse the config file (since currently the config file is mapped directly to a protobuf where policy_version is an 'int' and is shared with EncryptionOptions). Resolves https://github.com/google/fscrypt/issues/182
There's no real need to allow users to choose the key description prefix (a.k.a. the "service"), since on ext4 and f2fs we can just use "ext4" and "f2fs" for compatibility with all kernels both old and new, and on other filesystems we can just use "fscrypt". So, let's do that. Since this removes the point of the "--legacy" option to 'fscrypt setup' and the "compatibility" field in /etc/fscrypt.conf, remove those too. Specifically, we start ignoring the "compatibility" in existing config files and not writing it to new ones. The corresponding protobuf field number and name are reserved. We stop accepting the "--legacy" option at all, although since it was default true and there was no real reason for anyone to change it to false, probably no one will notice. If anyone does, they should just stop specifying the option. Note that this change only affects user keyrings and thus only affects v1 encryption policies, which are deprecated in favor of v2 anyway.
Ensure that when an encryption policy is reverted (e.g. due to encryptPath() failing after the policy was created), we also delete any new protector links that were created for the policy, as this is not handled by the logic that reverts new protectors.
When adding a protector to a policy, don't unconditionally overwrite the protector link, because it may already exist. Instead, if it already exists and points to the mount, just use it. If it already exists and points to the wrong place, return an error. Also add a bool to the return value of AddLinkedProtector() so that callers can check whether the link was newly created or not.
Ensure that a failed AddRecoveryPassphrase() doesn't leave around an unneeded protector file.
If the login protector was just created by the same 'fscrypt encrypt'
command, then policy.Context.Config.Source will be pam_passphrase. This
needs to be overridden to custom_passphrase when creating the protector
for the recovery passphrase.
This fixes the following error:
fscrypt encrypt: login protectors do not need a name
Resolves https://github.com/google/fscrypt/issues/187
Update https://github.com/google/fscrypt/issues/186
If a user re-installs their system (or otherwise loses the /.fscrypt directory on the root filesystem) they also lose access to any login passphrase-protected directories on other filesystems, unless additional protectors were manually added. This can be unexpected, as it may be expected that the old login passphrase would still work. We can't really fix this by storing a login protector on every filesystem because: - If a user were to have N login protectors, it would take them N times longer to log in, as every login protector would need to be unlocked. - If a user were to change their login passphrase while any external volumes were unmounted, login protectors would get out of sync. - It's preferable that an external volume isn't unlockable by itself using only a login passphrase, as login passphrases are often weak. Instead, generate a recovery passphrase when creating a login passphrase-protected directory on a non-root filesystem. The recovery passphrase is added as a custom_passphrase protector, thus giving the policy two protectors: one pam_passphrase and one custom_passphrase. Then this passphrase is written to a file in the new encrypted directory. Writing the passphrase to a file here is okay since it's encrypted, but it's obviously useless by itself; it's up to the user to store this passphrase somewhere else if they need it. Use a recovery passphrase instead of a "recovery code" that encodes the policy key directly because a passphrase is more user-friendly: it can safely be made much shorter than a key, and it works just like any other fscrypt protector. Also, it's not as critical to allow recovery when the .fscrypt directory on the *same* filesystem is deleted. Resolves https://github.com/google/fscrypt/issues/164
Allow root to provide the --all-users option to 'fscrypt lock' to force an encryption key to be removed from the filesystem (i.e., force an encrypted directory to be locked), even if other users have added it. To implement this option, we just need to use the FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl rather than FS_IOC_REMOVE_ENCRYPTION_KEY. In theory this option could be implemented for the user keyrings case too, but it would be difficult and the user keyrings are being deprecated for fscrypt, so don't bother.
Implement adding/removing v2 encryption policy keys to/from the kernel. The kernel requires that the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY be used for this. Root is not required. However, non-root support brings an extra complication: the kernel keeps track of which users have called FS_IOC_ADD_ENCRYPTION_KEY for the same key. FS_IOC_REMOVE_ENCRYPTION_KEY only works as one of these users, and it only removes the calling user's claim to the key; the key is only truly removed when the last claim is removed. Implement the following behavior: - 'fscrypt unlock' and pam_fscrypt add the key for the user, even if other user(s) have it added already. This behavior is needed so that another user can't remove the key out from under the user. - 'fscrypt lock' and pam_fscrypt remove the key for the user. However, if the key wasn't truly removed because other users still have it added, 'fscrypt lock' prints a warning. - 'fscrypt status' shows whether the directory is unlocked for anyone.