fscrypt: require that key be added when setting a v2 encryption policy

By looking up the master keys in a filesystem-level keyring rather than
in the calling processes' key hierarchy, it becomes possible for a user
to set an encryption policy which refers to some key they don't actually
know, then encrypt their files using that key.  Cryptographically this
isn't much of a problem, but the semantics of this would be a bit weird.
Thus, enforce that a v2 encryption policy can only be set if the user
has previously added the key, or has capable(CAP_FOWNER).

We tolerate that this problem will continue to exist for v1 encryption
policies, however; there is no way around that.

Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
This commit is contained in:
Eric Biggers 2019-08-04 19:35:48 -07:00
parent 78a1b96bcf
commit 5ab7189a31
3 changed files with 63 additions and 1 deletions

View File

@ -431,6 +431,9 @@ extern struct key *
fscrypt_find_master_key(struct super_block *sb,
const struct fscrypt_key_specifier *mk_spec);
extern int fscrypt_verify_key_added(struct super_block *sb,
const u8 identifier[FSCRYPT_KEY_IDENTIFIER_SIZE]);
extern int __init fscrypt_init_keyring(void);
/* keysetup.c */

View File

@ -562,6 +562,53 @@ int fscrypt_ioctl_add_key(struct file *filp, void __user *_uarg)
}
EXPORT_SYMBOL_GPL(fscrypt_ioctl_add_key);
/*
* Verify that the current user has added a master key with the given identifier
* (returns -ENOKEY if not). This is needed to prevent a user from encrypting
* their files using some other user's key which they don't actually know.
* Cryptographically this isn't much of a problem, but the semantics of this
* would be a bit weird, so it's best to just forbid it.
*
* The system administrator (CAP_FOWNER) can override this, which should be
* enough for any use cases where encryption policies are being set using keys
* that were chosen ahead of time but aren't available at the moment.
*
* Note that the key may have already removed by the time this returns, but
* that's okay; we just care whether the key was there at some point.
*
* Return: 0 if the key is added, -ENOKEY if it isn't, or another -errno code
*/
int fscrypt_verify_key_added(struct super_block *sb,
const u8 identifier[FSCRYPT_KEY_IDENTIFIER_SIZE])
{
struct fscrypt_key_specifier mk_spec;
struct key *key, *mk_user;
struct fscrypt_master_key *mk;
int err;
mk_spec.type = FSCRYPT_KEY_SPEC_TYPE_IDENTIFIER;
memcpy(mk_spec.u.identifier, identifier, FSCRYPT_KEY_IDENTIFIER_SIZE);
key = fscrypt_find_master_key(sb, &mk_spec);
if (IS_ERR(key)) {
err = PTR_ERR(key);
goto out;
}
mk = key->payload.data[0];
mk_user = find_master_key_user(mk);
if (IS_ERR(mk_user)) {
err = PTR_ERR(mk_user);
} else {
key_put(mk_user);
err = 0;
}
key_put(key);
out:
if (err == -ENOKEY && capable(CAP_FOWNER))
err = 0;
return err;
}
/*
* Try to evict the inode's dentries from the dentry cache. If the inode is a
* directory, then it can have at most one dentry; however, that dentry may be

View File

@ -233,11 +233,13 @@ static int set_encryption_policy(struct inode *inode,
{
union fscrypt_context ctx;
int ctxsize;
int err;
if (!fscrypt_supported_policy(policy, inode))
return -EINVAL;
if (policy->version == FSCRYPT_POLICY_V1) {
switch (policy->version) {
case FSCRYPT_POLICY_V1:
/*
* The original encryption policy version provided no way of
* verifying that the correct master key was supplied, which was
@ -251,6 +253,16 @@ static int set_encryption_policy(struct inode *inode,
*/
pr_warn_once("%s (pid %d) is setting deprecated v1 encryption policy; recommend upgrading to v2.\n",
current->comm, current->pid);
break;
case FSCRYPT_POLICY_V2:
err = fscrypt_verify_key_added(inode->i_sb,
policy->v2.master_key_identifier);
if (err)
return err;
break;
default:
WARN_ON(1);
return -EINVAL;
}
ctxsize = fscrypt_new_context_from_policy(&ctx, policy);