diff options
| author | Eric Biggers <ebiggers@google.com> | 2019-08-05 05:35:48 +0300 |
|---|---|---|
| committer | Eric Biggers <ebiggers@google.com> | 2019-08-13 05:18:50 +0300 |
| commit | 5ab7189a31bad40e4b44020cae6e56c8074721a1 (patch) | |
| tree | d9cea4d978ce732bd9e97ded7782ebb2ec600829 /fs/crypto/fscrypt_private.h | |
| parent | 78a1b96bcf7a0721c7852bb1475218c3cbef884a (diff) | |
| download | linux-5ab7189a31bad40e4b44020cae6e56c8074721a1.tar.xz | |
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>
Diffstat (limited to 'fs/crypto/fscrypt_private.h')
| -rw-r--r-- | fs/crypto/fscrypt_private.h | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index d0e238234234..e84efc01512e 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -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 */ |