2015-04-12 00:55:06 -04:00
|
|
|
/*
|
|
|
|
|
* linux/fs/ext4/crypto_key.c
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2015, Google, Inc.
|
|
|
|
|
*
|
|
|
|
|
* This contains encryption key functions for ext4
|
|
|
|
|
*
|
|
|
|
|
* Written by Michael Halcrow, Ildar Muslukhov, and Uday Savagaonkar, 2015.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <keys/encrypted-type.h>
|
|
|
|
|
#include <keys/user-type.h>
|
|
|
|
|
#include <linux/random.h>
|
|
|
|
|
#include <linux/scatterlist.h>
|
|
|
|
|
#include <uapi/linux/keyctl.h>
|
|
|
|
|
|
|
|
|
|
#include "ext4.h"
|
|
|
|
|
#include "xattr.h"
|
|
|
|
|
|
|
|
|
|
static void derive_crypt_complete(struct crypto_async_request *req, int rc)
|
|
|
|
|
{
|
|
|
|
|
struct ext4_completion_result *ecr = req->data;
|
|
|
|
|
|
|
|
|
|
if (rc == -EINPROGRESS)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
ecr->res = rc;
|
|
|
|
|
complete(&ecr->completion);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* ext4_derive_key_aes() - Derive a key using AES-128-ECB
|
2015-07-22 00:09:45 -04:00
|
|
|
* @deriving_key: Encryption key used for derivation.
|
2015-04-12 00:55:06 -04:00
|
|
|
* @source_key: Source key to which to apply derivation.
|
|
|
|
|
* @derived_key: Derived key.
|
|
|
|
|
*
|
|
|
|
|
* Return: Zero on success; non-zero otherwise.
|
|
|
|
|
*/
|
|
|
|
|
static int ext4_derive_key_aes(char deriving_key[EXT4_AES_128_ECB_KEY_SIZE],
|
|
|
|
|
char source_key[EXT4_AES_256_XTS_KEY_SIZE],
|
|
|
|
|
char derived_key[EXT4_AES_256_XTS_KEY_SIZE])
|
|
|
|
|
{
|
|
|
|
|
int res = 0;
|
|
|
|
|
struct ablkcipher_request *req = NULL;
|
|
|
|
|
DECLARE_EXT4_COMPLETION_RESULT(ecr);
|
|
|
|
|
struct scatterlist src_sg, dst_sg;
|
|
|
|
|
struct crypto_ablkcipher *tfm = crypto_alloc_ablkcipher("ecb(aes)", 0,
|
|
|
|
|
0);
|
|
|
|
|
|
|
|
|
|
if (IS_ERR(tfm)) {
|
|
|
|
|
res = PTR_ERR(tfm);
|
|
|
|
|
tfm = NULL;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
crypto_ablkcipher_set_flags(tfm, CRYPTO_TFM_REQ_WEAK_KEY);
|
|
|
|
|
req = ablkcipher_request_alloc(tfm, GFP_NOFS);
|
|
|
|
|
if (!req) {
|
|
|
|
|
res = -ENOMEM;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
ablkcipher_request_set_callback(req,
|
|
|
|
|
CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
|
|
|
|
|
derive_crypt_complete, &ecr);
|
|
|
|
|
res = crypto_ablkcipher_setkey(tfm, deriving_key,
|
|
|
|
|
EXT4_AES_128_ECB_KEY_SIZE);
|
|
|
|
|
if (res < 0)
|
|
|
|
|
goto out;
|
|
|
|
|
sg_init_one(&src_sg, source_key, EXT4_AES_256_XTS_KEY_SIZE);
|
|
|
|
|
sg_init_one(&dst_sg, derived_key, EXT4_AES_256_XTS_KEY_SIZE);
|
|
|
|
|
ablkcipher_request_set_crypt(req, &src_sg, &dst_sg,
|
|
|
|
|
EXT4_AES_256_XTS_KEY_SIZE, NULL);
|
|
|
|
|
res = crypto_ablkcipher_encrypt(req);
|
|
|
|
|
if (res == -EINPROGRESS || res == -EBUSY) {
|
|
|
|
|
wait_for_completion(&ecr.completion);
|
|
|
|
|
res = ecr.res;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
if (req)
|
|
|
|
|
ablkcipher_request_free(req);
|
|
|
|
|
if (tfm)
|
|
|
|
|
crypto_free_ablkcipher(tfm);
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-31 13:34:22 -04:00
|
|
|
void ext4_free_crypt_info(struct ext4_crypt_info *ci)
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
{
|
|
|
|
|
if (!ci)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
crypto_free_ablkcipher(ci->ci_ctfm);
|
2015-05-18 13:19:47 -04:00
|
|
|
kmem_cache_free(ext4_crypt_info_cachep, ci);
|
2015-05-31 13:34:22 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ext4_free_encryption_info(struct inode *inode,
|
|
|
|
|
struct ext4_crypt_info *ci)
|
|
|
|
|
{
|
|
|
|
|
struct ext4_inode_info *ei = EXT4_I(inode);
|
|
|
|
|
struct ext4_crypt_info *prev;
|
|
|
|
|
|
|
|
|
|
if (ci == NULL)
|
|
|
|
|
ci = ACCESS_ONCE(ei->i_crypt_info);
|
|
|
|
|
if (ci == NULL)
|
|
|
|
|
return;
|
|
|
|
|
prev = cmpxchg(&ei->i_crypt_info, ci, NULL);
|
|
|
|
|
if (prev != ci)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
ext4_free_crypt_info(ci);
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
}
|
|
|
|
|
|
fscrypt: remove broken support for detecting keyring key revocation
commit 1b53cf9815bb4744958d41f3795d5d5a1d365e2d upstream.
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-21 15:07:11 -08:00
|
|
|
int ext4_get_encryption_info(struct inode *inode)
|
2015-04-12 00:55:06 -04:00
|
|
|
{
|
|
|
|
|
struct ext4_inode_info *ei = EXT4_I(inode);
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
struct ext4_crypt_info *crypt_info;
|
2015-04-12 00:55:06 -04:00
|
|
|
char full_key_descriptor[EXT4_KEY_DESC_PREFIX_SIZE +
|
|
|
|
|
(EXT4_KEY_DESCRIPTOR_SIZE * 2) + 1];
|
|
|
|
|
struct key *keyring_key = NULL;
|
|
|
|
|
struct ext4_encryption_key *master_key;
|
|
|
|
|
struct ext4_encryption_context ctx;
|
2015-10-21 14:04:48 +01:00
|
|
|
const struct user_key_payload *ukp;
|
2015-04-16 01:56:00 -04:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
|
2015-05-31 13:34:22 -04:00
|
|
|
struct crypto_ablkcipher *ctfm;
|
|
|
|
|
const char *cipher_str;
|
|
|
|
|
char raw_key[EXT4_MAX_KEY_SIZE];
|
|
|
|
|
char mode;
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
int res;
|
2015-04-12 00:55:06 -04:00
|
|
|
|
fscrypt: remove broken support for detecting keyring key revocation
commit 1b53cf9815bb4744958d41f3795d5d5a1d365e2d upstream.
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-21 15:07:11 -08:00
|
|
|
if (ei->i_crypt_info)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2015-05-18 13:19:47 -04:00
|
|
|
if (!ext4_read_workqueue) {
|
|
|
|
|
res = ext4_init_crypto();
|
|
|
|
|
if (res)
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
res = ext4_xattr_get(inode, EXT4_XATTR_INDEX_ENCRYPTION,
|
|
|
|
|
EXT4_XATTR_NAME_ENCRYPTION_CONTEXT,
|
|
|
|
|
&ctx, sizeof(ctx));
|
|
|
|
|
if (res < 0) {
|
|
|
|
|
if (!DUMMY_ENCRYPTION_ENABLED(sbi))
|
|
|
|
|
return res;
|
|
|
|
|
ctx.contents_encryption_mode = EXT4_ENCRYPTION_MODE_AES_256_XTS;
|
|
|
|
|
ctx.filenames_encryption_mode =
|
|
|
|
|
EXT4_ENCRYPTION_MODE_AES_256_CTS;
|
|
|
|
|
ctx.flags = 0;
|
|
|
|
|
} else if (res != sizeof(ctx))
|
|
|
|
|
return -EINVAL;
|
2015-04-12 00:55:06 -04:00
|
|
|
res = 0;
|
|
|
|
|
|
2015-05-18 13:19:47 -04:00
|
|
|
crypt_info = kmem_cache_alloc(ext4_crypt_info_cachep, GFP_KERNEL);
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
if (!crypt_info)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
crypt_info->ci_flags = ctx.flags;
|
|
|
|
|
crypt_info->ci_data_mode = ctx.contents_encryption_mode;
|
|
|
|
|
crypt_info->ci_filename_mode = ctx.filenames_encryption_mode;
|
|
|
|
|
crypt_info->ci_ctfm = NULL;
|
|
|
|
|
memcpy(crypt_info->ci_master_key, ctx.master_key_descriptor,
|
|
|
|
|
sizeof(crypt_info->ci_master_key));
|
2015-04-16 01:56:00 -04:00
|
|
|
if (S_ISREG(inode->i_mode))
|
2015-05-31 13:34:22 -04:00
|
|
|
mode = crypt_info->ci_data_mode;
|
2015-04-16 01:56:00 -04:00
|
|
|
else if (S_ISDIR(inode->i_mode) || S_ISLNK(inode->i_mode))
|
2015-05-31 13:34:22 -04:00
|
|
|
mode = crypt_info->ci_filename_mode;
|
2015-05-18 13:20:47 -04:00
|
|
|
else
|
2015-04-16 01:56:00 -04:00
|
|
|
BUG();
|
2015-05-31 13:34:22 -04:00
|
|
|
switch (mode) {
|
|
|
|
|
case EXT4_ENCRYPTION_MODE_AES_256_XTS:
|
|
|
|
|
cipher_str = "xts(aes)";
|
|
|
|
|
break;
|
|
|
|
|
case EXT4_ENCRYPTION_MODE_AES_256_CTS:
|
|
|
|
|
cipher_str = "cts(cbc(aes))";
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
printk_once(KERN_WARNING
|
|
|
|
|
"ext4: unsupported key mode %d (ino %u)\n",
|
|
|
|
|
mode, (unsigned) inode->i_ino);
|
|
|
|
|
res = -ENOKEY;
|
2015-04-16 01:56:00 -04:00
|
|
|
goto out;
|
|
|
|
|
}
|
2015-05-31 13:34:22 -04:00
|
|
|
if (DUMMY_ENCRYPTION_ENABLED(sbi)) {
|
|
|
|
|
memset(raw_key, 0x42, EXT4_AES_256_XTS_KEY_SIZE);
|
|
|
|
|
goto got_key;
|
|
|
|
|
}
|
2015-04-12 00:55:06 -04:00
|
|
|
memcpy(full_key_descriptor, EXT4_KEY_DESC_PREFIX,
|
|
|
|
|
EXT4_KEY_DESC_PREFIX_SIZE);
|
|
|
|
|
sprintf(full_key_descriptor + EXT4_KEY_DESC_PREFIX_SIZE,
|
|
|
|
|
"%*phN", EXT4_KEY_DESCRIPTOR_SIZE,
|
|
|
|
|
ctx.master_key_descriptor);
|
|
|
|
|
full_key_descriptor[EXT4_KEY_DESC_PREFIX_SIZE +
|
|
|
|
|
(2 * EXT4_KEY_DESCRIPTOR_SIZE)] = '\0';
|
|
|
|
|
keyring_key = request_key(&key_type_logon, full_key_descriptor, NULL);
|
|
|
|
|
if (IS_ERR(keyring_key)) {
|
|
|
|
|
res = PTR_ERR(keyring_key);
|
|
|
|
|
keyring_key = NULL;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2015-10-03 10:49:27 -04:00
|
|
|
if (keyring_key->type != &key_type_logon) {
|
|
|
|
|
printk_once(KERN_WARNING
|
|
|
|
|
"ext4: key type must be logon\n");
|
|
|
|
|
res = -ENOKEY;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2015-12-10 00:57:58 -05:00
|
|
|
down_read(&keyring_key->sem);
|
2015-10-21 14:04:48 +01:00
|
|
|
ukp = user_key_payload(keyring_key);
|
2015-04-12 00:55:06 -04:00
|
|
|
if (ukp->datalen != sizeof(struct ext4_encryption_key)) {
|
|
|
|
|
res = -EINVAL;
|
2015-12-10 00:57:58 -05:00
|
|
|
up_read(&keyring_key->sem);
|
2015-04-12 00:55:06 -04:00
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
master_key = (struct ext4_encryption_key *)ukp->data;
|
|
|
|
|
BUILD_BUG_ON(EXT4_AES_128_ECB_KEY_SIZE !=
|
|
|
|
|
EXT4_KEY_DERIVATION_NONCE_SIZE);
|
2015-10-03 10:49:27 -04:00
|
|
|
if (master_key->size != EXT4_AES_256_XTS_KEY_SIZE) {
|
|
|
|
|
printk_once(KERN_WARNING
|
|
|
|
|
"ext4: key size incorrect: %d\n",
|
|
|
|
|
master_key->size);
|
|
|
|
|
res = -ENOKEY;
|
2015-12-10 00:57:58 -05:00
|
|
|
up_read(&keyring_key->sem);
|
2015-10-03 10:49:27 -04:00
|
|
|
goto out;
|
|
|
|
|
}
|
2015-05-18 13:16:47 -04:00
|
|
|
res = ext4_derive_key_aes(ctx.nonce, master_key->raw,
|
2015-05-31 13:34:22 -04:00
|
|
|
raw_key);
|
2015-12-10 00:57:58 -05:00
|
|
|
up_read(&keyring_key->sem);
|
2015-07-22 00:08:08 -04:00
|
|
|
if (res)
|
|
|
|
|
goto out;
|
2015-05-31 13:34:22 -04:00
|
|
|
got_key:
|
|
|
|
|
ctfm = crypto_alloc_ablkcipher(cipher_str, 0, 0);
|
|
|
|
|
if (!ctfm || IS_ERR(ctfm)) {
|
|
|
|
|
res = ctfm ? PTR_ERR(ctfm) : -ENOMEM;
|
|
|
|
|
printk(KERN_DEBUG
|
|
|
|
|
"%s: error %d (inode %u) allocating crypto tfm\n",
|
|
|
|
|
__func__, res, (unsigned) inode->i_ino);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
crypt_info->ci_ctfm = ctfm;
|
|
|
|
|
crypto_ablkcipher_clear_flags(ctfm, ~0);
|
|
|
|
|
crypto_tfm_set_flags(crypto_ablkcipher_tfm(ctfm),
|
|
|
|
|
CRYPTO_TFM_REQ_WEAK_KEY);
|
|
|
|
|
res = crypto_ablkcipher_setkey(ctfm, raw_key,
|
|
|
|
|
ext4_encryption_key_size(mode));
|
|
|
|
|
if (res)
|
|
|
|
|
goto out;
|
|
|
|
|
|
fscrypt: remove broken support for detecting keyring key revocation
commit 1b53cf9815bb4744958d41f3795d5d5a1d365e2d upstream.
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-21 15:07:11 -08:00
|
|
|
if (cmpxchg(&ei->i_crypt_info, NULL, crypt_info) == NULL)
|
|
|
|
|
crypt_info = NULL;
|
2015-05-31 13:34:22 -04:00
|
|
|
out:
|
|
|
|
|
if (res == -ENOKEY)
|
|
|
|
|
res = 0;
|
fscrypt: remove broken support for detecting keyring key revocation
commit 1b53cf9815bb4744958d41f3795d5d5a1d365e2d upstream.
Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again. This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.
This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired. Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory. Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem. In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.
In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches. But this is a hard problem, and for now this bug must be fixed.
This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.
Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-21 15:07:11 -08:00
|
|
|
key_put(keyring_key);
|
2015-05-31 13:34:22 -04:00
|
|
|
ext4_free_crypt_info(crypt_info);
|
|
|
|
|
memzero_explicit(raw_key, sizeof(raw_key));
|
2015-04-12 00:55:06 -04:00
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int ext4_has_encryption_key(struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
struct ext4_inode_info *ei = EXT4_I(inode);
|
|
|
|
|
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
return (ei->i_crypt_info != NULL);
|
2015-04-12 00:55:06 -04:00
|
|
|
}
|
