ErrKeyLock: Rename to ErrMlockUlimit for clarity. ErrGetrandomFail: ErrKeyAlloc: ErrKeyFree: ErrNegativeLength: Replace these with one-off unnamed errors because these were all returned in only one place and were never checked for. Also these were all either wrapped backwards or discarded an underlying error, so fix that too.
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
Linux v5.4 and later supports v2 encryption policies. These have several advantages over v1 encryption policies: - Their encryption keys can be added/removed to/from the filesystem by non-root users, thus gaining the benefits of the filesystem keyring while also retaining support for non-root use. - They use a more standard, secure, and flexible key derivation function. Because of this, some future kernel-level fscrypt features will be implemented for v2 policies only. - They prevent a denial-of-service attack where a user could associate the wrong key with another user's encrypted files. Prepare the fscrypt tool to support v2 encryption policies by: - Adding a policy_version field to the EncryptionOptions, i.e. to the config file and to the policy metadata files. - Using the kernel-specified algorithm to compute the key descriptor for v2 policies. - Handling setting and getting v2 policies. Actually adding/removing the keys for v2 policies to/from the kernel is left for the next patch.
In preparation for introducing support for the new filesystem-level keyrings, move the existing user keyring management code from security/keyring.go and crypto/crypto.go into a new package, 'keyring'. This package provides functions AddEncryptionKey, RemoveEncryptionKey, and GetEncryptionKeyStatus which delegate to either the filesystem keyring (added by a later patch) or to the user keyring. This provides a common interface to both types of keyrings, to the extent possible.
Refer to the target User as 'targetUser' rather than simply 'target'. This will help avoid confusion when we add support for the filesystem keyring, since then the Mount will also be a "target".
Use the new name for fscrypt constants and structures which have been given a new name. Also use the named constant for the DIRECT_KEY fscrypt policy flag. No change in behavior. This is just preparing for future work.
These were found by a combination of manual review and a custom script that checks for common errors. Also removed an outdated sentence from the comment for setupBefore().
Running "go vet -shadow ./..." finds all places where a variable might be incorrectly or unnecessarily shadowed. This fixes some of them.
Use the golang library for the hashing function instead of the reference C implementation. This removes the dependancy on libargon2. As we are no longer doing our own error checking, we also eliminate those tests.