License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2015-05-16 07:26:10 +08:00
|
|
|
/*
|
|
|
|
* Encryption policy functions for per-file encryption support.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2015, Google, Inc.
|
|
|
|
* Copyright (C) 2015, Motorola Mobility.
|
|
|
|
*
|
|
|
|
* Written by Michael Halcrow, 2015.
|
|
|
|
* Modified by Jaegeuk Kim, 2015.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/random.h>
|
|
|
|
#include <linux/string.h>
|
2016-09-09 05:20:38 +08:00
|
|
|
#include <linux/mount.h>
|
2016-11-27 11:05:18 +08:00
|
|
|
#include "fscrypt_private.h"
|
2015-05-16 07:26:10 +08:00
|
|
|
|
|
|
|
/*
|
2016-12-06 03:12:48 +08:00
|
|
|
* check whether an encryption policy is consistent with an encryption context
|
2015-05-16 07:26:10 +08:00
|
|
|
*/
|
2016-12-06 03:12:48 +08:00
|
|
|
static bool is_encryption_context_consistent_with_policy(
|
|
|
|
const struct fscrypt_context *ctx,
|
2015-05-16 07:26:10 +08:00
|
|
|
const struct fscrypt_policy *policy)
|
|
|
|
{
|
2016-12-06 03:12:48 +08:00
|
|
|
return memcmp(ctx->master_key_descriptor, policy->master_key_descriptor,
|
|
|
|
FS_KEY_DESCRIPTOR_SIZE) == 0 &&
|
|
|
|
(ctx->flags == policy->flags) &&
|
|
|
|
(ctx->contents_encryption_mode ==
|
|
|
|
policy->contents_encryption_mode) &&
|
|
|
|
(ctx->filenames_encryption_mode ==
|
|
|
|
policy->filenames_encryption_mode);
|
2015-05-16 07:26:10 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int create_encryption_context_from_policy(struct inode *inode,
|
|
|
|
const struct fscrypt_policy *policy)
|
|
|
|
{
|
|
|
|
struct fscrypt_context ctx;
|
|
|
|
|
|
|
|
ctx.format = FS_ENCRYPTION_CONTEXT_FORMAT_V1;
|
|
|
|
memcpy(ctx.master_key_descriptor, policy->master_key_descriptor,
|
|
|
|
FS_KEY_DESCRIPTOR_SIZE);
|
|
|
|
|
2017-06-19 15:27:58 +08:00
|
|
|
if (!fscrypt_valid_enc_modes(policy->contents_encryption_mode,
|
|
|
|
policy->filenames_encryption_mode))
|
2015-05-16 07:26:10 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (policy->flags & ~FS_POLICY_FLAGS_VALID)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ctx.contents_encryption_mode = policy->contents_encryption_mode;
|
|
|
|
ctx.filenames_encryption_mode = policy->filenames_encryption_mode;
|
|
|
|
ctx.flags = policy->flags;
|
|
|
|
BUILD_BUG_ON(sizeof(ctx.nonce) != FS_KEY_DERIVATION_NONCE_SIZE);
|
|
|
|
get_random_bytes(ctx.nonce, FS_KEY_DERIVATION_NONCE_SIZE);
|
|
|
|
|
|
|
|
return inode->i_sb->s_cop->set_context(inode, &ctx, sizeof(ctx), NULL);
|
|
|
|
}
|
|
|
|
|
2016-11-27 08:07:49 +08:00
|
|
|
int fscrypt_ioctl_set_policy(struct file *filp, const void __user *arg)
|
2015-05-16 07:26:10 +08:00
|
|
|
{
|
2016-11-27 08:07:49 +08:00
|
|
|
struct fscrypt_policy policy;
|
2016-09-09 05:20:38 +08:00
|
|
|
struct inode *inode = file_inode(filp);
|
|
|
|
int ret;
|
2016-12-06 03:12:48 +08:00
|
|
|
struct fscrypt_context ctx;
|
2016-09-09 05:20:38 +08:00
|
|
|
|
2016-11-27 08:07:49 +08:00
|
|
|
if (copy_from_user(&policy, arg, sizeof(policy)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
2016-09-09 01:57:08 +08:00
|
|
|
if (!inode_owner_or_capable(inode))
|
|
|
|
return -EACCES;
|
|
|
|
|
2016-11-27 08:07:49 +08:00
|
|
|
if (policy.version != 0)
|
2015-05-16 07:26:10 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2016-09-09 05:20:38 +08:00
|
|
|
ret = mnt_want_write_file(filp);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-10-15 21:48:50 +08:00
|
|
|
inode_lock(inode);
|
|
|
|
|
2016-12-06 03:12:48 +08:00
|
|
|
ret = inode->i_sb->s_cop->get_context(inode, &ctx, sizeof(ctx));
|
|
|
|
if (ret == -ENODATA) {
|
2016-09-09 02:36:39 +08:00
|
|
|
if (!S_ISDIR(inode->i_mode))
|
2016-12-06 03:12:45 +08:00
|
|
|
ret = -ENOTDIR;
|
2016-09-09 05:20:38 +08:00
|
|
|
else if (!inode->i_sb->s_cop->empty_dir(inode))
|
|
|
|
ret = -ENOTEMPTY;
|
|
|
|
else
|
|
|
|
ret = create_encryption_context_from_policy(inode,
|
2016-11-27 08:07:49 +08:00
|
|
|
&policy);
|
2016-12-06 03:12:48 +08:00
|
|
|
} else if (ret == sizeof(ctx) &&
|
|
|
|
is_encryption_context_consistent_with_policy(&ctx,
|
|
|
|
&policy)) {
|
|
|
|
/* The file already uses the same encryption policy. */
|
|
|
|
ret = 0;
|
|
|
|
} else if (ret >= 0 || ret == -ERANGE) {
|
|
|
|
/* The file already uses a different encryption policy. */
|
2016-12-06 03:12:46 +08:00
|
|
|
ret = -EEXIST;
|
2015-05-16 07:26:10 +08:00
|
|
|
}
|
|
|
|
|
2016-10-15 21:48:50 +08:00
|
|
|
inode_unlock(inode);
|
|
|
|
|
2016-09-09 05:20:38 +08:00
|
|
|
mnt_drop_write_file(filp);
|
|
|
|
return ret;
|
2015-05-16 07:26:10 +08:00
|
|
|
}
|
2016-11-27 08:07:49 +08:00
|
|
|
EXPORT_SYMBOL(fscrypt_ioctl_set_policy);
|
2015-05-16 07:26:10 +08:00
|
|
|
|
2016-11-27 08:07:49 +08:00
|
|
|
int fscrypt_ioctl_get_policy(struct file *filp, void __user *arg)
|
2015-05-16 07:26:10 +08:00
|
|
|
{
|
2016-11-27 08:07:49 +08:00
|
|
|
struct inode *inode = file_inode(filp);
|
2015-05-16 07:26:10 +08:00
|
|
|
struct fscrypt_context ctx;
|
2016-11-27 08:07:49 +08:00
|
|
|
struct fscrypt_policy policy;
|
2015-05-16 07:26:10 +08:00
|
|
|
int res;
|
|
|
|
|
2017-10-10 03:15:36 +08:00
|
|
|
if (!IS_ENCRYPTED(inode))
|
2015-05-16 07:26:10 +08:00
|
|
|
return -ENODATA;
|
|
|
|
|
|
|
|
res = inode->i_sb->s_cop->get_context(inode, &ctx, sizeof(ctx));
|
2016-12-06 03:12:48 +08:00
|
|
|
if (res < 0 && res != -ERANGE)
|
|
|
|
return res;
|
2015-05-16 07:26:10 +08:00
|
|
|
if (res != sizeof(ctx))
|
2016-12-06 03:12:48 +08:00
|
|
|
return -EINVAL;
|
2015-05-16 07:26:10 +08:00
|
|
|
if (ctx.format != FS_ENCRYPTION_CONTEXT_FORMAT_V1)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2016-11-27 08:07:49 +08:00
|
|
|
policy.version = 0;
|
|
|
|
policy.contents_encryption_mode = ctx.contents_encryption_mode;
|
|
|
|
policy.filenames_encryption_mode = ctx.filenames_encryption_mode;
|
|
|
|
policy.flags = ctx.flags;
|
|
|
|
memcpy(policy.master_key_descriptor, ctx.master_key_descriptor,
|
2015-05-16 07:26:10 +08:00
|
|
|
FS_KEY_DESCRIPTOR_SIZE);
|
2016-11-27 08:07:49 +08:00
|
|
|
|
|
|
|
if (copy_to_user(arg, &policy, sizeof(policy)))
|
|
|
|
return -EFAULT;
|
2015-05-16 07:26:10 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2016-11-27 08:07:49 +08:00
|
|
|
EXPORT_SYMBOL(fscrypt_ioctl_get_policy);
|
2015-05-16 07:26:10 +08:00
|
|
|
|
fscrypt: fix context consistency check when key(s) unavailable
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-04-08 01:58:37 +08:00
|
|
|
/**
|
|
|
|
* fscrypt_has_permitted_context() - is a file's encryption policy permitted
|
|
|
|
* within its directory?
|
|
|
|
*
|
|
|
|
* @parent: inode for parent directory
|
|
|
|
* @child: inode for file being looked up, opened, or linked into @parent
|
|
|
|
*
|
|
|
|
* Filesystems must call this before permitting access to an inode in a
|
|
|
|
* situation where the parent directory is encrypted (either before allowing
|
|
|
|
* ->lookup() to succeed, or for a regular file before allowing it to be opened)
|
|
|
|
* and before any operation that involves linking an inode into an encrypted
|
|
|
|
* directory, including link, rename, and cross rename. It enforces the
|
|
|
|
* constraint that within a given encrypted directory tree, all files use the
|
|
|
|
* same encryption policy. The pre-access check is needed to detect potentially
|
|
|
|
* malicious offline violations of this constraint, while the link and rename
|
|
|
|
* checks are needed to prevent online violations of this constraint.
|
|
|
|
*
|
fscrypt: return -EXDEV for incompatible rename or link into encrypted dir
Currently, trying to rename or link a regular file, directory, or
symlink into an encrypted directory fails with EPERM when the source
file is unencrypted or is encrypted with a different encryption policy,
and is on the same mountpoint. It is correct for the operation to fail,
but the choice of EPERM breaks tools like 'mv' that know to copy rather
than rename if they see EXDEV, but don't know what to do with EPERM.
Our original motivation for EPERM was to encourage users to securely
handle their data. Encrypting files by "moving" them into an encrypted
directory can be insecure because the unencrypted data may remain in
free space on disk, where it can later be recovered by an attacker.
It's much better to encrypt the data from the start, or at least try to
securely delete the source data e.g. using the 'shred' program.
However, the current behavior hasn't been effective at achieving its
goal because users tend to be confused, hack around it, and complain;
see e.g. https://github.com/google/fscrypt/issues/76. And in some cases
it's actually inconsistent or unnecessary. For example, 'mv'-ing files
between differently encrypted directories doesn't work even in cases
where it can be secure, such as when in userspace the same passphrase
protects both directories. Yet, you *can* already 'mv' unencrypted
files into an encrypted directory if the source files are on a different
mountpoint, even though doing so is often insecure.
There are probably better ways to teach users to securely handle their
files. For example, the 'fscrypt' userspace tool could provide a
command that migrates unencrypted files into an encrypted directory,
acting like 'shred' on the source files and providing appropriate
warnings depending on the type of the source filesystem and disk.
Receiving errors on unimportant files might also force some users to
disable encryption, thus making the behavior counterproductive. It's
desirable to make encryption as unobtrusive as possible.
Therefore, change the error code from EPERM to EXDEV so that tools
looking for EXDEV will fall back to a copy.
This, of course, doesn't prevent users from still doing the right things
to securely manage their files. Note that this also matches the
behavior when a file is renamed between two project quota hierarchies;
so there's precedent for using EXDEV for things other than mountpoints.
xfstests generic/398 will require an update with this change.
[Rewritten from an earlier patch series by Michael Halcrow.]
Cc: Michael Halcrow <mhalcrow@google.com>
Cc: Joe Richey <joerichey@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-01-23 08:20:21 +08:00
|
|
|
* Return: 1 if permitted, 0 if forbidden.
|
fscrypt: fix context consistency check when key(s) unavailable
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-04-08 01:58:37 +08:00
|
|
|
*/
|
2015-05-16 07:26:10 +08:00
|
|
|
int fscrypt_has_permitted_context(struct inode *parent, struct inode *child)
|
|
|
|
{
|
fscrypt: fix context consistency check when key(s) unavailable
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-04-08 01:58:37 +08:00
|
|
|
const struct fscrypt_operations *cops = parent->i_sb->s_cop;
|
|
|
|
const struct fscrypt_info *parent_ci, *child_ci;
|
|
|
|
struct fscrypt_context parent_ctx, child_ctx;
|
2015-05-16 07:26:10 +08:00
|
|
|
int res;
|
|
|
|
|
2016-12-20 06:20:13 +08:00
|
|
|
/* No restrictions on file types which are never encrypted */
|
|
|
|
if (!S_ISREG(child->i_mode) && !S_ISDIR(child->i_mode) &&
|
|
|
|
!S_ISLNK(child->i_mode))
|
|
|
|
return 1;
|
|
|
|
|
fscrypt: fix context consistency check when key(s) unavailable
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-04-08 01:58:37 +08:00
|
|
|
/* No restrictions if the parent directory is unencrypted */
|
2017-10-10 03:15:36 +08:00
|
|
|
if (!IS_ENCRYPTED(parent))
|
2015-05-16 07:26:10 +08:00
|
|
|
return 1;
|
fscrypt: fix context consistency check when key(s) unavailable
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-04-08 01:58:37 +08:00
|
|
|
|
|
|
|
/* Encrypted directories must not contain unencrypted files */
|
2017-10-10 03:15:36 +08:00
|
|
|
if (!IS_ENCRYPTED(child))
|
2015-05-16 07:26:10 +08:00
|
|
|
return 0;
|
fscrypt: fix context consistency check when key(s) unavailable
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-04-08 01:58:37 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Both parent and child are encrypted, so verify they use the same
|
|
|
|
* encryption policy. Compare the fscrypt_info structs if the keys are
|
|
|
|
* available, otherwise retrieve and compare the fscrypt_contexts.
|
|
|
|
*
|
|
|
|
* Note that the fscrypt_context retrieval will be required frequently
|
|
|
|
* when accessing an encrypted directory tree without the key.
|
|
|
|
* Performance-wise this is not a big deal because we already don't
|
|
|
|
* really optimize for file access without the key (to the extent that
|
|
|
|
* such access is even possible), given that any attempted access
|
|
|
|
* already causes a fscrypt_context retrieval and keyring search.
|
|
|
|
*
|
|
|
|
* In any case, if an unexpected error occurs, fall back to "forbidden".
|
|
|
|
*/
|
|
|
|
|
2015-05-16 07:26:10 +08:00
|
|
|
res = fscrypt_get_encryption_info(parent);
|
|
|
|
if (res)
|
|
|
|
return 0;
|
|
|
|
res = fscrypt_get_encryption_info(child);
|
|
|
|
if (res)
|
|
|
|
return 0;
|
2019-04-12 05:32:15 +08:00
|
|
|
parent_ci = READ_ONCE(parent->i_crypt_info);
|
|
|
|
child_ci = READ_ONCE(child->i_crypt_info);
|
fscrypt: fix context consistency check when key(s) unavailable
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-04-08 01:58:37 +08:00
|
|
|
|
|
|
|
if (parent_ci && child_ci) {
|
fscrypt: add Adiantum support
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2019-01-06 21:36:21 +08:00
|
|
|
return memcmp(parent_ci->ci_master_key_descriptor,
|
|
|
|
child_ci->ci_master_key_descriptor,
|
fscrypt: fix context consistency check when key(s) unavailable
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-04-08 01:58:37 +08:00
|
|
|
FS_KEY_DESCRIPTOR_SIZE) == 0 &&
|
|
|
|
(parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
|
|
|
|
(parent_ci->ci_filename_mode ==
|
|
|
|
child_ci->ci_filename_mode) &&
|
|
|
|
(parent_ci->ci_flags == child_ci->ci_flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
res = cops->get_context(parent, &parent_ctx, sizeof(parent_ctx));
|
|
|
|
if (res != sizeof(parent_ctx))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
res = cops->get_context(child, &child_ctx, sizeof(child_ctx));
|
|
|
|
if (res != sizeof(child_ctx))
|
2015-05-16 07:26:10 +08:00
|
|
|
return 0;
|
|
|
|
|
fscrypt: fix context consistency check when key(s) unavailable
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-04-08 01:58:37 +08:00
|
|
|
return memcmp(parent_ctx.master_key_descriptor,
|
|
|
|
child_ctx.master_key_descriptor,
|
|
|
|
FS_KEY_DESCRIPTOR_SIZE) == 0 &&
|
|
|
|
(parent_ctx.contents_encryption_mode ==
|
|
|
|
child_ctx.contents_encryption_mode) &&
|
|
|
|
(parent_ctx.filenames_encryption_mode ==
|
|
|
|
child_ctx.filenames_encryption_mode) &&
|
|
|
|
(parent_ctx.flags == child_ctx.flags);
|
2015-05-16 07:26:10 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(fscrypt_has_permitted_context);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* fscrypt_inherit_context() - Sets a child context from its parent
|
|
|
|
* @parent: Parent inode from which the context is inherited.
|
|
|
|
* @child: Child inode that inherits the context from @parent.
|
|
|
|
* @fs_data: private data given by FS.
|
2017-01-03 04:12:17 +08:00
|
|
|
* @preload: preload child i_crypt_info if true
|
2015-05-16 07:26:10 +08:00
|
|
|
*
|
2017-01-03 04:12:17 +08:00
|
|
|
* Return: 0 on success, -errno on failure
|
2015-05-16 07:26:10 +08:00
|
|
|
*/
|
|
|
|
int fscrypt_inherit_context(struct inode *parent, struct inode *child,
|
|
|
|
void *fs_data, bool preload)
|
|
|
|
{
|
|
|
|
struct fscrypt_context ctx;
|
|
|
|
struct fscrypt_info *ci;
|
|
|
|
int res;
|
|
|
|
|
|
|
|
res = fscrypt_get_encryption_info(parent);
|
|
|
|
if (res < 0)
|
|
|
|
return res;
|
|
|
|
|
2019-04-12 05:32:15 +08:00
|
|
|
ci = READ_ONCE(parent->i_crypt_info);
|
2015-05-16 07:26:10 +08:00
|
|
|
if (ci == NULL)
|
|
|
|
return -ENOKEY;
|
|
|
|
|
|
|
|
ctx.format = FS_ENCRYPTION_CONTEXT_FORMAT_V1;
|
2017-01-03 04:12:17 +08:00
|
|
|
ctx.contents_encryption_mode = ci->ci_data_mode;
|
|
|
|
ctx.filenames_encryption_mode = ci->ci_filename_mode;
|
|
|
|
ctx.flags = ci->ci_flags;
|
fscrypt: add Adiantum support
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adiantum: length-preserving encryption for entry-level processors"
(https://eprint.iacr.org/2018/720.pdf) for more details. Also see
commit 059c2a4d8e16 ("crypto: adiantum - add Adiantum support").
On sufficiently long messages, Adiantum's bottlenecks are XChaCha12 and
the NH hash function. These algorithms are fast even on processors
without dedicated crypto instructions. Adiantum makes it feasible to
enable storage encryption on low-end mobile devices that lack AES
instructions; currently such devices are unencrypted. On ARM Cortex-A7,
on 4096-byte messages Adiantum encryption is about 4 times faster than
AES-256-XTS encryption; decryption is about 5 times faster.
In fscrypt, Adiantum is suitable for encrypting both file contents and
names. With filenames, it fixes a known weakness: when two filenames in
a directory share a common prefix of >= 16 bytes, with CTS-CBC their
encrypted filenames share a common prefix too, leaking information.
Adiantum does not have this problem.
Since Adiantum also accepts long tweaks (IVs), it's also safe to use the
master key directly for Adiantum encryption rather than deriving
per-file keys, provided that the per-file nonce is included in the IVs
and the master key isn't used for any other encryption mode. This
configuration saves memory and improves performance. A new fscrypt
policy flag is added to allow users to opt-in to this configuration.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2019-01-06 21:36:21 +08:00
|
|
|
memcpy(ctx.master_key_descriptor, ci->ci_master_key_descriptor,
|
2017-01-03 04:12:17 +08:00
|
|
|
FS_KEY_DESCRIPTOR_SIZE);
|
2015-05-16 07:26:10 +08:00
|
|
|
get_random_bytes(ctx.nonce, FS_KEY_DERIVATION_NONCE_SIZE);
|
2017-07-06 12:01:59 +08:00
|
|
|
BUILD_BUG_ON(sizeof(ctx) != FSCRYPT_SET_CONTEXT_MAX_SIZE);
|
2015-05-16 07:26:10 +08:00
|
|
|
res = parent->i_sb->s_cop->set_context(child, &ctx,
|
|
|
|
sizeof(ctx), fs_data);
|
|
|
|
if (res)
|
|
|
|
return res;
|
|
|
|
return preload ? fscrypt_get_encryption_info(child): 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(fscrypt_inherit_context);
|