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 14:07:57 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2015-04-26 07:12:50 +00:00
|
|
|
/*
|
2015-05-15 23:26:10 +00:00
|
|
|
* This contains functions for filename crypto management
|
2015-04-26 07:12:50 +00:00
|
|
|
*
|
|
|
|
* Copyright (C) 2015, Google, Inc.
|
|
|
|
* Copyright (C) 2015, Motorola Mobility
|
|
|
|
*
|
|
|
|
* Written by Uday Savagaonkar, 2014.
|
2015-05-15 23:26:10 +00:00
|
|
|
* Modified by Jaegeuk Kim, 2015.
|
2015-04-26 07:12:50 +00:00
|
|
|
*
|
|
|
|
* This has not yet undergone a rigorous security audit.
|
|
|
|
*/
|
2015-05-15 23:26:10 +00:00
|
|
|
|
2019-12-09 20:43:59 +00:00
|
|
|
#include <linux/namei.h>
|
2015-04-26 07:12:50 +00:00
|
|
|
#include <linux/scatterlist.h>
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
#include <crypto/hash.h>
|
|
|
|
#include <crypto/sha.h>
|
2018-01-05 18:45:00 +00:00
|
|
|
#include <crypto/skcipher.h>
|
2016-11-27 01:32:46 +00:00
|
|
|
#include "fscrypt_private.h"
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2020-05-11 19:13:56 +00:00
|
|
|
/*
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
* struct fscrypt_nokey_name - identifier for directory entry when key is absent
|
|
|
|
*
|
|
|
|
* When userspace lists an encrypted directory without access to the key, the
|
|
|
|
* filesystem must present a unique "no-key name" for each filename that allows
|
|
|
|
* it to find the directory entry again if requested. Naively, that would just
|
|
|
|
* mean using the ciphertext filenames. However, since the ciphertext filenames
|
|
|
|
* can contain illegal characters ('\0' and '/'), they must be encoded in some
|
|
|
|
* way. We use base64. But that can cause names to exceed NAME_MAX (255
|
|
|
|
* bytes), so we also need to use a strong hash to abbreviate long names.
|
|
|
|
*
|
|
|
|
* The filesystem may also need another kind of hash, the "dirhash", to quickly
|
|
|
|
* find the directory entry. Since filesystems normally compute the dirhash
|
|
|
|
* over the on-disk filename (i.e. the ciphertext), it's not computable from
|
|
|
|
* no-key names that abbreviate the ciphertext using the strong hash to fit in
|
|
|
|
* NAME_MAX. It's also not computable if it's a keyed hash taken over the
|
|
|
|
* plaintext (but it may still be available in the on-disk directory entry);
|
|
|
|
* casefolded directories use this type of dirhash. At least in these cases,
|
|
|
|
* each no-key name must include the name's dirhash too.
|
|
|
|
*
|
|
|
|
* To meet all these requirements, we base64-encode the following
|
|
|
|
* variable-length structure. It contains the dirhash, or 0's if the filesystem
|
|
|
|
* didn't provide one; up to 149 bytes of the ciphertext name; and for
|
|
|
|
* ciphertexts longer than 149 bytes, also the SHA-256 of the remaining bytes.
|
|
|
|
*
|
|
|
|
* This ensures that each no-key name contains everything needed to find the
|
|
|
|
* directory entry again, contains only legal characters, doesn't exceed
|
|
|
|
* NAME_MAX, is unambiguous unless there's a SHA-256 collision, and that we only
|
|
|
|
* take the performance hit of SHA-256 on very long filenames (which are rare).
|
|
|
|
*/
|
|
|
|
struct fscrypt_nokey_name {
|
|
|
|
u32 dirhash[2];
|
|
|
|
u8 bytes[149];
|
|
|
|
u8 sha256[SHA256_DIGEST_SIZE];
|
|
|
|
}; /* 189 bytes => 252 bytes base64-encoded, which is <= NAME_MAX (255) */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Decoded size of max-size nokey name, i.e. a name that was abbreviated using
|
|
|
|
* the strong hash and thus includes the 'sha256' field. This isn't simply
|
|
|
|
* sizeof(struct fscrypt_nokey_name), as the padding at the end isn't included.
|
|
|
|
*/
|
|
|
|
#define FSCRYPT_NOKEY_NAME_MAX offsetofend(struct fscrypt_nokey_name, sha256)
|
|
|
|
|
2020-07-21 22:59:16 +00:00
|
|
|
static void fscrypt_do_sha256(const u8 *data, unsigned int data_len, u8 *result)
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
{
|
2020-07-21 22:59:16 +00:00
|
|
|
struct sha256_state sctx;
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
|
2020-07-21 22:59:16 +00:00
|
|
|
sha256_init(&sctx);
|
|
|
|
sha256_update(&sctx, data, data_len);
|
|
|
|
sha256_final(&sctx, result);
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
}
|
|
|
|
|
2018-01-05 18:44:59 +00:00
|
|
|
static inline bool fscrypt_is_dot_dotdot(const struct qstr *str)
|
|
|
|
{
|
|
|
|
if (str->len == 1 && str->name[0] == '.')
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (str->len == 2 && str->name[0] == '.' && str->name[1] == '.')
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-04-26 07:12:50 +00:00
|
|
|
/**
|
2020-01-20 07:17:36 +00:00
|
|
|
* fscrypt_fname_encrypt() - encrypt a filename
|
2020-05-11 19:13:56 +00:00
|
|
|
* @inode: inode of the parent directory (for regular filenames)
|
|
|
|
* or of the symlink (for symlink targets)
|
|
|
|
* @iname: the filename to encrypt
|
|
|
|
* @out: (output) the encrypted filename
|
|
|
|
* @olen: size of the encrypted filename. It must be at least @iname->len.
|
|
|
|
* Any extra space is filled with NUL padding before encryption.
|
2016-09-15 21:25:55 +00:00
|
|
|
*
|
|
|
|
* Return: 0 on success, -errno on failure
|
2015-04-26 07:12:50 +00:00
|
|
|
*/
|
2020-01-20 07:17:36 +00:00
|
|
|
int fscrypt_fname_encrypt(const struct inode *inode, const struct qstr *iname,
|
|
|
|
u8 *out, unsigned int olen)
|
2015-04-26 07:12:50 +00:00
|
|
|
{
|
2016-01-24 13:17:49 +00:00
|
|
|
struct skcipher_request *req = NULL;
|
2017-10-18 07:00:44 +00:00
|
|
|
DECLARE_CRYPTO_WAIT(wait);
|
2019-12-15 21:39:47 +00:00
|
|
|
const struct fscrypt_info *ci = inode->i_crypt_info;
|
2020-07-02 01:56:05 +00:00
|
|
|
struct crypto_skcipher *tfm = ci->ci_enc_key.tfm;
|
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 13:36:21 +00:00
|
|
|
union fscrypt_iv iv;
|
2016-11-14 01:35:52 +00:00
|
|
|
struct scatterlist sg;
|
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 13:36:21 +00:00
|
|
|
int res;
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2016-11-14 01:35:52 +00:00
|
|
|
/*
|
|
|
|
* Copy the filename to the output buffer for encrypting in-place and
|
|
|
|
* pad it with the needed number of NUL bytes.
|
|
|
|
*/
|
2018-01-12 04:30:08 +00:00
|
|
|
if (WARN_ON(olen < iname->len))
|
fscrypt: new helper functions for ->symlink()
Currently, filesystems supporting fscrypt need to implement some tricky
logic when creating encrypted symlinks, including handling a peculiar
on-disk format (struct fscrypt_symlink_data) and correctly calculating
the size of the encrypted symlink. Introduce helper functions to make
things a bit easier:
- fscrypt_prepare_symlink() computes and validates the size the symlink
target will require on-disk.
- fscrypt_encrypt_symlink() creates the encrypted target if needed.
The new helpers actually fix some subtle bugs. First, when checking
whether the symlink target was too long, filesystems didn't account for
the fact that the NUL padding is meant to be truncated if it would cause
the maximum length to be exceeded, as is done for filenames in
directories. Consequently users would receive ENAMETOOLONG when
creating symlinks close to what is supposed to be the maximum length.
For example, with EXT4 with a 4K block size, the maximum symlink target
length in an encrypted directory is supposed to be 4093 bytes (in
comparison to 4095 in an unencrypted directory), but in
FS_POLICY_FLAGS_PAD_32-mode only up to 4064 bytes were accepted.
Second, symlink targets of "." and ".." were not being encrypted, even
though they should be, as these names are special in *directory entries*
but not in symlink targets. Fortunately, we can fix this simply by
starting to encrypt them, as old kernels already accept them in
encrypted form.
Third, the output string length the filesystems were providing when
doing the actual encryption was incorrect, as it was forgotten to
exclude 'sizeof(struct fscrypt_symlink_data)'. Fortunately though, this
bug didn't make a difference.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2018-01-05 18:45:01 +00:00
|
|
|
return -ENOBUFS;
|
2018-01-12 04:30:08 +00:00
|
|
|
memcpy(out, iname->name, iname->len);
|
|
|
|
memset(out + iname->len, 0, olen - iname->len);
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2016-11-14 01:35:52 +00:00
|
|
|
/* Initialize the IV */
|
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 13:36:21 +00:00
|
|
|
fscrypt_generate_iv(&iv, 0, ci);
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2016-11-14 01:35:52 +00:00
|
|
|
/* Set up the encryption request */
|
2016-01-24 13:17:49 +00:00
|
|
|
req = skcipher_request_alloc(tfm, GFP_NOFS);
|
2018-04-30 22:51:38 +00:00
|
|
|
if (!req)
|
2015-04-26 07:12:50 +00:00
|
|
|
return -ENOMEM;
|
2016-01-24 13:17:49 +00:00
|
|
|
skcipher_request_set_callback(req,
|
2015-04-26 07:12:50 +00:00
|
|
|
CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
|
2017-10-18 07:00:44 +00:00
|
|
|
crypto_req_done, &wait);
|
2018-01-12 04:30:08 +00:00
|
|
|
sg_init_one(&sg, out, olen);
|
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 13:36:21 +00:00
|
|
|
skcipher_request_set_crypt(req, &sg, &sg, olen, &iv);
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2016-11-14 01:35:52 +00:00
|
|
|
/* Do the encryption */
|
2017-10-18 07:00:44 +00:00
|
|
|
res = crypto_wait_req(crypto_skcipher_encrypt(req), &wait);
|
2016-01-24 13:17:49 +00:00
|
|
|
skcipher_request_free(req);
|
2016-09-15 21:25:55 +00:00
|
|
|
if (res < 0) {
|
2019-07-24 18:07:58 +00:00
|
|
|
fscrypt_err(inode, "Filename encryption failed: %d", res);
|
2016-09-15 21:25:55 +00:00
|
|
|
return res;
|
|
|
|
}
|
2015-05-15 23:26:10 +00:00
|
|
|
|
2016-09-15 21:25:55 +00:00
|
|
|
return 0;
|
2015-04-26 07:12:50 +00:00
|
|
|
}
|
|
|
|
|
2016-09-15 21:25:55 +00:00
|
|
|
/**
|
|
|
|
* fname_decrypt() - decrypt a filename
|
2020-05-11 19:13:56 +00:00
|
|
|
* @inode: inode of the parent directory (for regular filenames)
|
|
|
|
* or of the symlink (for symlink targets)
|
|
|
|
* @iname: the encrypted filename to decrypt
|
|
|
|
* @oname: (output) the decrypted filename. The caller must have allocated
|
|
|
|
* enough space for this, e.g. using fscrypt_fname_alloc_buffer().
|
2016-09-15 21:25:55 +00:00
|
|
|
*
|
|
|
|
* Return: 0 on success, -errno on failure
|
2015-04-26 07:12:50 +00:00
|
|
|
*/
|
2019-12-15 21:39:47 +00:00
|
|
|
static int fname_decrypt(const struct inode *inode,
|
|
|
|
const struct fscrypt_str *iname,
|
|
|
|
struct fscrypt_str *oname)
|
2015-04-26 07:12:50 +00:00
|
|
|
{
|
2016-01-24 13:17:49 +00:00
|
|
|
struct skcipher_request *req = NULL;
|
2017-10-18 07:00:44 +00:00
|
|
|
DECLARE_CRYPTO_WAIT(wait);
|
2015-04-26 07:12:50 +00:00
|
|
|
struct scatterlist src_sg, dst_sg;
|
2019-12-15 21:39:47 +00:00
|
|
|
const struct fscrypt_info *ci = inode->i_crypt_info;
|
2020-07-02 01:56:05 +00:00
|
|
|
struct crypto_skcipher *tfm = ci->ci_enc_key.tfm;
|
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 13:36:21 +00:00
|
|
|
union fscrypt_iv iv;
|
|
|
|
int res;
|
2015-04-26 07:12:50 +00:00
|
|
|
|
|
|
|
/* Allocate request */
|
2016-01-24 13:17:49 +00:00
|
|
|
req = skcipher_request_alloc(tfm, GFP_NOFS);
|
2018-04-30 22:51:38 +00:00
|
|
|
if (!req)
|
2015-04-26 07:12:50 +00:00
|
|
|
return -ENOMEM;
|
2016-01-24 13:17:49 +00:00
|
|
|
skcipher_request_set_callback(req,
|
2015-04-26 07:12:50 +00:00
|
|
|
CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
|
2017-10-18 07:00:44 +00:00
|
|
|
crypto_req_done, &wait);
|
2015-04-26 07:12:50 +00:00
|
|
|
|
|
|
|
/* Initialize IV */
|
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 13:36:21 +00:00
|
|
|
fscrypt_generate_iv(&iv, 0, ci);
|
2015-04-26 07:12:50 +00:00
|
|
|
|
|
|
|
/* Create decryption request */
|
|
|
|
sg_init_one(&src_sg, iname->name, iname->len);
|
|
|
|
sg_init_one(&dst_sg, oname->name, oname->len);
|
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 13:36:21 +00:00
|
|
|
skcipher_request_set_crypt(req, &src_sg, &dst_sg, iname->len, &iv);
|
2017-10-18 07:00:44 +00:00
|
|
|
res = crypto_wait_req(crypto_skcipher_decrypt(req), &wait);
|
2016-01-24 13:17:49 +00:00
|
|
|
skcipher_request_free(req);
|
2015-04-26 07:12:50 +00:00
|
|
|
if (res < 0) {
|
2019-07-24 18:07:58 +00:00
|
|
|
fscrypt_err(inode, "Filename decryption failed: %d", res);
|
2015-04-26 07:12:50 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
oname->len = strnlen(oname->name, iname->len);
|
2016-09-15 21:25:55 +00:00
|
|
|
return 0;
|
2015-04-26 07:12:50 +00:00
|
|
|
}
|
|
|
|
|
2019-07-24 18:07:58 +00:00
|
|
|
static const char lookup_table[65] =
|
2015-04-26 07:12:50 +00:00
|
|
|
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
|
|
|
|
|
2017-04-24 17:00:10 +00:00
|
|
|
#define BASE64_CHARS(nbytes) DIV_ROUND_UP((nbytes) * 4, 3)
|
|
|
|
|
2015-04-26 07:12:50 +00:00
|
|
|
/**
|
2020-05-11 19:13:56 +00:00
|
|
|
* base64_encode() - base64-encode some bytes
|
|
|
|
* @src: the bytes to encode
|
|
|
|
* @len: number of bytes to encode
|
|
|
|
* @dst: (output) the base64-encoded string. Not NUL-terminated.
|
2015-04-26 07:12:50 +00:00
|
|
|
*
|
2019-07-24 18:07:58 +00:00
|
|
|
* Encodes the input string using characters from the set [A-Za-z0-9+,].
|
2015-04-26 07:12:50 +00:00
|
|
|
* The encoded string is roughly 4/3 times the size of the input string.
|
2019-07-24 18:07:58 +00:00
|
|
|
*
|
|
|
|
* Return: length of the encoded string
|
2015-04-26 07:12:50 +00:00
|
|
|
*/
|
2019-07-24 18:07:58 +00:00
|
|
|
static int base64_encode(const u8 *src, int len, char *dst)
|
2015-04-26 07:12:50 +00:00
|
|
|
{
|
2019-07-24 18:07:58 +00:00
|
|
|
int i, bits = 0, ac = 0;
|
2015-04-26 07:12:50 +00:00
|
|
|
char *cp = dst;
|
|
|
|
|
2019-07-24 18:07:58 +00:00
|
|
|
for (i = 0; i < len; i++) {
|
|
|
|
ac += src[i] << bits;
|
2015-04-26 07:12:50 +00:00
|
|
|
bits += 8;
|
|
|
|
do {
|
|
|
|
*cp++ = lookup_table[ac & 0x3f];
|
|
|
|
ac >>= 6;
|
|
|
|
bits -= 6;
|
|
|
|
} while (bits >= 6);
|
|
|
|
}
|
|
|
|
if (bits)
|
|
|
|
*cp++ = lookup_table[ac & 0x3f];
|
|
|
|
return cp - dst;
|
|
|
|
}
|
|
|
|
|
2019-07-24 18:07:58 +00:00
|
|
|
static int base64_decode(const char *src, int len, u8 *dst)
|
2015-04-26 07:12:50 +00:00
|
|
|
{
|
2019-07-24 18:07:58 +00:00
|
|
|
int i, bits = 0, ac = 0;
|
2015-04-26 07:12:50 +00:00
|
|
|
const char *p;
|
2019-07-24 18:07:58 +00:00
|
|
|
u8 *cp = dst;
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2019-07-24 18:07:58 +00:00
|
|
|
for (i = 0; i < len; i++) {
|
2015-04-26 07:12:50 +00:00
|
|
|
p = strchr(lookup_table, src[i]);
|
|
|
|
if (p == NULL || src[i] == 0)
|
|
|
|
return -2;
|
|
|
|
ac += (p - lookup_table) << bits;
|
|
|
|
bits += 6;
|
|
|
|
if (bits >= 8) {
|
|
|
|
*cp++ = ac & 0xff;
|
|
|
|
ac >>= 8;
|
|
|
|
bits -= 8;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (ac)
|
|
|
|
return -1;
|
|
|
|
return cp - dst;
|
|
|
|
}
|
|
|
|
|
2018-01-12 04:30:08 +00:00
|
|
|
bool fscrypt_fname_encrypted_size(const struct inode *inode, u32 orig_len,
|
|
|
|
u32 max_len, u32 *encrypted_len_ret)
|
2015-04-26 07:12:50 +00:00
|
|
|
{
|
fscrypt: v2 encryption policy support
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it avoids the quirks and limitations of the AES-128-ECB based KDF.
Three classes of cryptographically isolated subkeys are defined:
- Per-file keys, like used in v1 policies except for the new KDF.
- Per-mode keys. These implement the semantics of the DIRECT_KEY
flag, which for v1 policies made the master key be used directly.
These are also planned to be used for inline encryption when
support for it is added.
- Key identifiers (see below).
- Each master key is identified by a 16-byte master_key_identifier,
which is derived from the key itself using HKDF-SHA512. This prevents
users from associating the wrong key with an encrypted file or
directory. This was easily possible with v1 policies, which
identified the key by an arbitrary 8-byte master_key_descriptor.
- The key must be provided in the filesystem-level keyring, not in a
process-subscribed keyring.
The following UAPI additions are made:
- The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
- A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
getting the v1 or v2 encryption policy of an encrypted file or
directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
be used because it did not have a way for userspace to indicate which
policy structure is expected. The new ioctl includes a size field, so
it is extensible to future fscrypt policy versions.
- The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
encryption policies. Such keys are kept logically separate from keys
for v1 encryption policies, and are identified by 'identifier' rather
than by 'descriptor'. The 'identifier' need not be provided when
adding a key, since the kernel will calculate it anyway.
This patch temporarily keeps adding/removing v2 policy keys behind the
same permission check done for adding/removing v1 policy keys:
capable(CAP_SYS_ADMIN). However, the next patch will carefully take
advantage of the cryptographically secure master_key_identifier to allow
non-root users to add/remove v2 policy keys, thus providing a full
replacement for v1 policies.
(*) Actually, in the API fscrypt_policy::version is 0 while on-disk
fscrypt_context::format is 1. But I believe it makes the most sense
to advance both to '2' to have them be in sync, and to consider the
numbering to start at 1 except for the API quirk.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-08-05 02:35:47 +00:00
|
|
|
const struct fscrypt_info *ci = inode->i_crypt_info;
|
|
|
|
int padding = 4 << (fscrypt_policy_flags(&ci->ci_policy) &
|
2019-08-05 02:35:44 +00:00
|
|
|
FSCRYPT_POLICY_FLAGS_PAD_MASK);
|
2018-01-12 04:30:08 +00:00
|
|
|
u32 encrypted_len;
|
|
|
|
|
|
|
|
if (orig_len > max_len)
|
|
|
|
return false;
|
|
|
|
encrypted_len = max(orig_len, (u32)FS_CRYPTO_BLOCK_SIZE);
|
|
|
|
encrypted_len = round_up(encrypted_len, padding);
|
|
|
|
*encrypted_len_ret = min(encrypted_len, max_len);
|
|
|
|
return true;
|
2015-04-26 07:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2020-05-11 19:13:56 +00:00
|
|
|
* fscrypt_fname_alloc_buffer() - allocate a buffer for presented filenames
|
|
|
|
* @max_encrypted_len: maximum length of encrypted filenames the buffer will be
|
|
|
|
* used to present
|
|
|
|
* @crypto_str: (output) buffer to allocate
|
2015-04-26 07:12:50 +00:00
|
|
|
*
|
2018-01-12 04:30:08 +00:00
|
|
|
* Allocate a buffer that is large enough to hold any decrypted or encoded
|
|
|
|
* filename (null-terminated), for the given maximum encrypted filename length.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, -errno on failure
|
2015-04-26 07:12:50 +00:00
|
|
|
*/
|
2020-08-10 14:21:39 +00:00
|
|
|
int fscrypt_fname_alloc_buffer(u32 max_encrypted_len,
|
2018-01-12 04:30:08 +00:00
|
|
|
struct fscrypt_str *crypto_str)
|
2015-04-26 07:12:50 +00:00
|
|
|
{
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
const u32 max_encoded_len = BASE64_CHARS(FSCRYPT_NOKEY_NAME_MAX);
|
2018-01-12 04:30:08 +00:00
|
|
|
u32 max_presented_len;
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2018-01-12 04:30:08 +00:00
|
|
|
max_presented_len = max(max_encoded_len, max_encrypted_len);
|
2017-04-24 17:00:10 +00:00
|
|
|
|
2018-01-12 04:30:08 +00:00
|
|
|
crypto_str->name = kmalloc(max_presented_len + 1, GFP_NOFS);
|
|
|
|
if (!crypto_str->name)
|
2015-04-26 07:12:50 +00:00
|
|
|
return -ENOMEM;
|
2018-01-12 04:30:08 +00:00
|
|
|
crypto_str->len = max_presented_len;
|
2015-04-26 07:12:50 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2015-05-15 23:26:10 +00:00
|
|
|
EXPORT_SYMBOL(fscrypt_fname_alloc_buffer);
|
2015-04-26 07:12:50 +00:00
|
|
|
|
|
|
|
/**
|
2020-05-11 19:13:56 +00:00
|
|
|
* fscrypt_fname_free_buffer() - free a buffer for presented filenames
|
|
|
|
* @crypto_str: the buffer to free
|
2015-04-26 07:12:50 +00:00
|
|
|
*
|
2020-05-11 19:13:56 +00:00
|
|
|
* Free a buffer that was allocated by fscrypt_fname_alloc_buffer().
|
2015-04-26 07:12:50 +00:00
|
|
|
*/
|
2015-05-15 23:26:10 +00:00
|
|
|
void fscrypt_fname_free_buffer(struct fscrypt_str *crypto_str)
|
2015-04-26 07:12:50 +00:00
|
|
|
{
|
|
|
|
if (!crypto_str)
|
|
|
|
return;
|
|
|
|
kfree(crypto_str->name);
|
|
|
|
crypto_str->name = NULL;
|
|
|
|
}
|
2015-05-15 23:26:10 +00:00
|
|
|
EXPORT_SYMBOL(fscrypt_fname_free_buffer);
|
2015-04-26 07:12:50 +00:00
|
|
|
|
|
|
|
/**
|
2020-05-11 19:13:56 +00:00
|
|
|
* fscrypt_fname_disk_to_usr() - convert an encrypted filename to
|
|
|
|
* user-presentable form
|
|
|
|
* @inode: inode of the parent directory (for regular filenames)
|
|
|
|
* or of the symlink (for symlink targets)
|
|
|
|
* @hash: first part of the name's dirhash, if applicable. This only needs to
|
|
|
|
* be provided if the filename is located in an indexed directory whose
|
|
|
|
* encryption key may be unavailable. Not needed for symlink targets.
|
|
|
|
* @minor_hash: second part of the name's dirhash, if applicable
|
|
|
|
* @iname: encrypted filename to convert. May also be "." or "..", which
|
|
|
|
* aren't actually encrypted.
|
|
|
|
* @oname: output buffer for the user-presentable filename. The caller must
|
|
|
|
* have allocated enough space for this, e.g. using
|
|
|
|
* fscrypt_fname_alloc_buffer().
|
2016-09-15 21:25:55 +00:00
|
|
|
*
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
* If the key is available, we'll decrypt the disk name. Otherwise, we'll
|
|
|
|
* encode it for presentation in fscrypt_nokey_name format.
|
|
|
|
* See struct fscrypt_nokey_name for details.
|
2017-04-24 17:00:10 +00:00
|
|
|
*
|
2016-09-15 21:25:55 +00:00
|
|
|
* Return: 0 on success, -errno on failure
|
2015-04-26 07:12:50 +00:00
|
|
|
*/
|
2019-12-15 21:39:47 +00:00
|
|
|
int fscrypt_fname_disk_to_usr(const struct inode *inode,
|
|
|
|
u32 hash, u32 minor_hash,
|
|
|
|
const struct fscrypt_str *iname,
|
|
|
|
struct fscrypt_str *oname)
|
2015-04-26 07:12:50 +00:00
|
|
|
{
|
|
|
|
const struct qstr qname = FSTR_TO_QSTR(iname);
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
struct fscrypt_nokey_name nokey_name;
|
|
|
|
u32 size; /* size of the unencoded no-key name */
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2015-05-15 23:26:10 +00:00
|
|
|
if (fscrypt_is_dot_dotdot(&qname)) {
|
2015-04-26 07:12:50 +00:00
|
|
|
oname->name[0] = '.';
|
|
|
|
oname->name[iname->len - 1] = '.';
|
|
|
|
oname->len = iname->len;
|
2016-09-15 21:25:55 +00:00
|
|
|
return 0;
|
2015-04-26 07:12:50 +00:00
|
|
|
}
|
|
|
|
|
2015-05-15 23:26:10 +00:00
|
|
|
if (iname->len < FS_CRYPTO_BLOCK_SIZE)
|
2016-02-06 03:37:27 +00:00
|
|
|
return -EUCLEAN;
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2019-04-11 21:32:15 +00:00
|
|
|
if (fscrypt_has_encryption_key(inode))
|
2015-05-15 23:26:10 +00:00
|
|
|
return fname_decrypt(inode, iname, oname);
|
|
|
|
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
/*
|
|
|
|
* Sanity check that struct fscrypt_nokey_name doesn't have padding
|
|
|
|
* between fields and that its encoded size never exceeds NAME_MAX.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(offsetofend(struct fscrypt_nokey_name, dirhash) !=
|
|
|
|
offsetof(struct fscrypt_nokey_name, bytes));
|
|
|
|
BUILD_BUG_ON(offsetofend(struct fscrypt_nokey_name, bytes) !=
|
|
|
|
offsetof(struct fscrypt_nokey_name, sha256));
|
|
|
|
BUILD_BUG_ON(BASE64_CHARS(FSCRYPT_NOKEY_NAME_MAX) > NAME_MAX);
|
|
|
|
|
2015-04-26 07:12:50 +00:00
|
|
|
if (hash) {
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
nokey_name.dirhash[0] = hash;
|
|
|
|
nokey_name.dirhash[1] = minor_hash;
|
2015-05-15 23:26:10 +00:00
|
|
|
} else {
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
nokey_name.dirhash[0] = 0;
|
|
|
|
nokey_name.dirhash[1] = 0;
|
2015-05-15 23:26:10 +00:00
|
|
|
}
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
if (iname->len <= sizeof(nokey_name.bytes)) {
|
|
|
|
memcpy(nokey_name.bytes, iname->name, iname->len);
|
|
|
|
size = offsetof(struct fscrypt_nokey_name, bytes[iname->len]);
|
|
|
|
} else {
|
|
|
|
memcpy(nokey_name.bytes, iname->name, sizeof(nokey_name.bytes));
|
|
|
|
/* Compute strong hash of remaining part of name. */
|
2020-07-21 22:59:16 +00:00
|
|
|
fscrypt_do_sha256(&iname->name[sizeof(nokey_name.bytes)],
|
|
|
|
iname->len - sizeof(nokey_name.bytes),
|
|
|
|
nokey_name.sha256);
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
size = FSCRYPT_NOKEY_NAME_MAX;
|
|
|
|
}
|
|
|
|
oname->len = base64_encode((const u8 *)&nokey_name, size, oname->name);
|
2016-09-15 21:25:55 +00:00
|
|
|
return 0;
|
2015-04-26 07:12:50 +00:00
|
|
|
}
|
2015-05-15 23:26:10 +00:00
|
|
|
EXPORT_SYMBOL(fscrypt_fname_disk_to_usr);
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2017-04-24 17:00:10 +00:00
|
|
|
/**
|
|
|
|
* fscrypt_setup_filename() - prepare to search a possibly encrypted directory
|
|
|
|
* @dir: the directory that will be searched
|
|
|
|
* @iname: the user-provided filename being searched for
|
|
|
|
* @lookup: 1 if we're allowed to proceed without the key because it's
|
|
|
|
* ->lookup() or we're finding the dir_entry for deletion; 0 if we cannot
|
|
|
|
* proceed without the key because we're going to create the dir_entry.
|
|
|
|
* @fname: the filename information to be filled in
|
|
|
|
*
|
|
|
|
* Given a user-provided filename @iname, this function sets @fname->disk_name
|
|
|
|
* to the name that would be stored in the on-disk directory entry, if possible.
|
|
|
|
* If the directory is unencrypted this is simply @iname. Else, if we have the
|
|
|
|
* directory's encryption key, then @iname is the plaintext, so we encrypt it to
|
|
|
|
* get the disk_name.
|
|
|
|
*
|
|
|
|
* Else, for keyless @lookup operations, @iname is the presented ciphertext, so
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
* we decode it to get the fscrypt_nokey_name. Non-@lookup operations will be
|
2017-04-24 17:00:10 +00:00
|
|
|
* impossible in this case, so we fail them with ENOKEY.
|
|
|
|
*
|
|
|
|
* If successful, fscrypt_free_filename() must be called later to clean up.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, -errno on failure
|
|
|
|
*/
|
2015-05-15 23:26:10 +00:00
|
|
|
int fscrypt_setup_filename(struct inode *dir, const struct qstr *iname,
|
|
|
|
int lookup, struct fscrypt_name *fname)
|
2015-04-26 07:12:50 +00:00
|
|
|
{
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
struct fscrypt_nokey_name *nokey_name;
|
2017-04-24 17:00:10 +00:00
|
|
|
int ret;
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2015-05-15 23:26:10 +00:00
|
|
|
memset(fname, 0, sizeof(struct fscrypt_name));
|
2015-04-26 07:12:50 +00:00
|
|
|
fname->usr_fname = iname;
|
|
|
|
|
2017-10-09 19:15:36 +00:00
|
|
|
if (!IS_ENCRYPTED(dir) || fscrypt_is_dot_dotdot(iname)) {
|
2015-04-26 07:12:50 +00:00
|
|
|
fname->disk_name.name = (unsigned char *)iname->name;
|
|
|
|
fname->disk_name.len = iname->len;
|
2015-05-13 10:20:54 +00:00
|
|
|
return 0;
|
2015-04-26 07:12:50 +00:00
|
|
|
}
|
fscrypt: remove broken support for detecting keyring key revocation
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")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Michael Halcrow <mhalcrow@google.com>
2017-02-21 23:07:11 +00:00
|
|
|
ret = fscrypt_get_encryption_info(dir);
|
2018-04-30 22:51:41 +00:00
|
|
|
if (ret)
|
2015-04-26 07:12:50 +00:00
|
|
|
return ret;
|
2015-05-15 23:26:10 +00:00
|
|
|
|
2019-04-11 21:32:15 +00:00
|
|
|
if (fscrypt_has_encryption_key(dir)) {
|
2018-01-12 04:30:08 +00:00
|
|
|
if (!fscrypt_fname_encrypted_size(dir, iname->len,
|
2018-04-30 22:51:44 +00:00
|
|
|
dir->i_sb->s_cop->max_namelen,
|
2018-01-12 04:30:08 +00:00
|
|
|
&fname->crypto_buf.len))
|
2018-01-12 04:30:08 +00:00
|
|
|
return -ENAMETOOLONG;
|
|
|
|
fname->crypto_buf.name = kmalloc(fname->crypto_buf.len,
|
|
|
|
GFP_NOFS);
|
|
|
|
if (!fname->crypto_buf.name)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2020-01-20 07:17:36 +00:00
|
|
|
ret = fscrypt_fname_encrypt(dir, iname, fname->crypto_buf.name,
|
|
|
|
fname->crypto_buf.len);
|
2016-09-15 21:25:55 +00:00
|
|
|
if (ret)
|
2015-05-29 00:06:40 +00:00
|
|
|
goto errout;
|
2015-04-26 07:12:50 +00:00
|
|
|
fname->disk_name.name = fname->crypto_buf.name;
|
|
|
|
fname->disk_name.len = fname->crypto_buf.len;
|
2015-05-13 10:20:54 +00:00
|
|
|
return 0;
|
2015-04-26 07:12:50 +00:00
|
|
|
}
|
2015-05-29 00:06:40 +00:00
|
|
|
if (!lookup)
|
2016-12-05 19:12:44 +00:00
|
|
|
return -ENOKEY;
|
fscrypt: fix race where ->lookup() marks plaintext dentry as ciphertext
->lookup() in an encrypted directory begins as follows:
1. fscrypt_prepare_lookup():
a. Try to load the directory's encryption key.
b. If the key is unavailable, mark the dentry as a ciphertext name
via d_flags.
2. fscrypt_setup_filename():
a. Try to load the directory's encryption key.
b. If the key is available, encrypt the name (treated as a plaintext
name) to get the on-disk name. Otherwise decode the name
(treated as a ciphertext name) to get the on-disk name.
But if the key is concurrently added, it may be found at (2a) but not at
(1a). In this case, the dentry will be wrongly marked as a ciphertext
name even though it was actually treated as plaintext.
This will cause the dentry to be wrongly invalidated on the next lookup,
potentially causing problems. For example, if the racy ->lookup() was
part of sys_mount(), then the new mount will be detached when anything
tries to access it. This is despite the mountpoint having a plaintext
path, which should remain valid now that the key was added.
Of course, this is only possible if there's a userspace race. Still,
the additional kernel-side race is confusing and unexpected.
Close the kernel-side race by changing fscrypt_prepare_lookup() to also
set the on-disk filename (step 2b), consistent with the d_flags update.
Fixes: 28b4c263961c ("ext4 crypto: revalidate dentry after adding or removing the key")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2019-03-20 18:39:13 +00:00
|
|
|
fname->is_ciphertext_name = true;
|
2015-04-26 07:12:50 +00:00
|
|
|
|
2015-05-15 23:26:10 +00:00
|
|
|
/*
|
|
|
|
* We don't have the key and we are doing a lookup; decode the
|
2015-04-26 07:12:50 +00:00
|
|
|
* user-supplied name
|
|
|
|
*/
|
2015-05-29 00:06:40 +00:00
|
|
|
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
if (iname->len > BASE64_CHARS(FSCRYPT_NOKEY_NAME_MAX))
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
fname->crypto_buf.name = kmalloc(FSCRYPT_NOKEY_NAME_MAX, GFP_KERNEL);
|
2015-05-29 00:06:40 +00:00
|
|
|
if (fname->crypto_buf.name == NULL)
|
|
|
|
return -ENOMEM;
|
2015-05-15 23:26:10 +00:00
|
|
|
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
ret = base64_decode(iname->name, iname->len, fname->crypto_buf.name);
|
|
|
|
if (ret < (int)offsetof(struct fscrypt_nokey_name, bytes[1]) ||
|
|
|
|
(ret > offsetof(struct fscrypt_nokey_name, sha256) &&
|
|
|
|
ret != FSCRYPT_NOKEY_NAME_MAX)) {
|
2015-04-26 07:12:50 +00:00
|
|
|
ret = -ENOENT;
|
2015-05-29 00:06:40 +00:00
|
|
|
goto errout;
|
2015-04-26 07:12:50 +00:00
|
|
|
}
|
|
|
|
fname->crypto_buf.len = ret;
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
|
|
|
|
nokey_name = (void *)fname->crypto_buf.name;
|
|
|
|
fname->hash = nokey_name->dirhash[0];
|
|
|
|
fname->minor_hash = nokey_name->dirhash[1];
|
|
|
|
if (ret != FSCRYPT_NOKEY_NAME_MAX) {
|
|
|
|
/* The full ciphertext filename is available. */
|
|
|
|
fname->disk_name.name = nokey_name->bytes;
|
|
|
|
fname->disk_name.len =
|
|
|
|
ret - offsetof(struct fscrypt_nokey_name, bytes);
|
2015-04-26 07:12:50 +00:00
|
|
|
}
|
2015-05-13 10:20:54 +00:00
|
|
|
return 0;
|
2015-05-15 23:26:10 +00:00
|
|
|
|
2015-05-29 00:06:40 +00:00
|
|
|
errout:
|
2018-01-12 04:30:08 +00:00
|
|
|
kfree(fname->crypto_buf.name);
|
2015-04-26 07:12:50 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2015-05-15 23:26:10 +00:00
|
|
|
EXPORT_SYMBOL(fscrypt_setup_filename);
|
2019-12-09 20:43:59 +00:00
|
|
|
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
/**
|
|
|
|
* fscrypt_match_name() - test whether the given name matches a directory entry
|
|
|
|
* @fname: the name being searched for
|
|
|
|
* @de_name: the name from the directory entry
|
|
|
|
* @de_name_len: the length of @de_name in bytes
|
|
|
|
*
|
|
|
|
* Normally @fname->disk_name will be set, and in that case we simply compare
|
|
|
|
* that to the name stored in the directory entry. The only exception is that
|
|
|
|
* if we don't have the key for an encrypted directory and the name we're
|
|
|
|
* looking for is very long, then we won't have the full disk_name and instead
|
|
|
|
* we'll need to match against a fscrypt_nokey_name that includes a strong hash.
|
|
|
|
*
|
|
|
|
* Return: %true if the name matches, otherwise %false.
|
|
|
|
*/
|
|
|
|
bool fscrypt_match_name(const struct fscrypt_name *fname,
|
|
|
|
const u8 *de_name, u32 de_name_len)
|
|
|
|
{
|
|
|
|
const struct fscrypt_nokey_name *nokey_name =
|
|
|
|
(const void *)fname->crypto_buf.name;
|
|
|
|
u8 sha256[SHA256_DIGEST_SIZE];
|
|
|
|
|
|
|
|
if (likely(fname->disk_name.name)) {
|
|
|
|
if (de_name_len != fname->disk_name.len)
|
|
|
|
return false;
|
|
|
|
return !memcmp(de_name, fname->disk_name.name, de_name_len);
|
|
|
|
}
|
|
|
|
if (de_name_len <= sizeof(nokey_name->bytes))
|
|
|
|
return false;
|
|
|
|
if (memcmp(de_name, nokey_name->bytes, sizeof(nokey_name->bytes)))
|
|
|
|
return false;
|
2020-07-21 22:59:16 +00:00
|
|
|
fscrypt_do_sha256(&de_name[sizeof(nokey_name->bytes)],
|
|
|
|
de_name_len - sizeof(nokey_name->bytes), sha256);
|
fscrypt: improve format of no-key names
When an encrypted directory is listed without the key, the filesystem
must show "no-key names" that uniquely identify directory entries, are
at most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.
Currently, for short names the no-key name is the base64 encoding of the
ciphertext filename, while for long names it's the base64 encoding of
the ciphertext filename's dirhash and second-to-last 16-byte block.
This format has the following problems:
- Since it doesn't always include the dirhash, it's incompatible with
directories that will use a secret-keyed dirhash over the plaintext
filenames. In this case, the dirhash won't be computable from the
ciphertext name without the key, so it instead must be retrieved from
the directory entry and always included in the no-key name.
Casefolded encrypted directories will use this type of dirhash.
- It's ambiguous: it's possible to craft two filenames that map to the
same no-key name, since the method used to abbreviate long filenames
doesn't use a proper cryptographic hash function.
Solve both these problems by switching to a new no-key name format that
is the base64 encoding of a variable-length structure that contains the
dirhash, up to 149 bytes of the ciphertext filename, and (if any bytes
remain) the SHA-256 of the remaining bytes of the ciphertext filename.
This ensures that each no-key name contains everything needed to find
the directory entry again, contains only legal characters, doesn't
exceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, and
that we only take the performance hit of SHA-256 on very long filenames.
Note: this change does *not* address the existing issue where users can
modify the 'dirhash' part of a no-key name and the filesystem may still
accept the name.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved comments and commit message, fixed checking return value
of base64_decode(), check for SHA-256 error, continue to set disk_name
for short names to keep matching simpler, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:32:01 +00:00
|
|
|
return !memcmp(sha256, nokey_name->sha256, sizeof(sha256));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(fscrypt_match_name);
|
|
|
|
|
fscrypt: derive dirhash key for casefolded directories
When we allow indexed directories to use both encryption and
casefolding, for the dirhash we can't just hash the ciphertext filenames
that are stored on-disk (as is done currently) because the dirhash must
be case insensitive, but the stored names are case-preserving. Nor can
we hash the plaintext names with an unkeyed hash (or a hash keyed with a
value stored on-disk like ext4's s_hash_seed), since that would leak
information about the names that encryption is meant to protect.
Instead, if we can accept a dirhash that's only computable when the
fscrypt key is available, we can hash the plaintext names with a keyed
hash using a secret key derived from the directory's fscrypt master key.
We'll use SipHash-2-4 for this purpose.
Prepare for this by deriving a SipHash key for each casefolded encrypted
directory. Make sure to handle deriving the key not only when setting
up the directory's fscrypt_info, but also in the case where the casefold
flag is enabled after the fscrypt_info was already set up. (We could
just always derive the key regardless of casefolding, but that would
introduce unnecessary overhead for people not using casefolding.)
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[EB: improved commit message, updated fscrypt.rst, squashed with change
that avoids unnecessarily deriving the key, and many other cleanups]
Link: https://lore.kernel.org/r/20200120223201.241390-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-20 22:31:57 +00:00
|
|
|
/**
|
|
|
|
* fscrypt_fname_siphash() - calculate the SipHash of a filename
|
|
|
|
* @dir: the parent directory
|
|
|
|
* @name: the filename to calculate the SipHash of
|
|
|
|
*
|
|
|
|
* Given a plaintext filename @name and a directory @dir which uses SipHash as
|
|
|
|
* its dirhash method and has had its fscrypt key set up, this function
|
|
|
|
* calculates the SipHash of that name using the directory's secret dirhash key.
|
|
|
|
*
|
|
|
|
* Return: the SipHash of @name using the hash key of @dir
|
|
|
|
*/
|
|
|
|
u64 fscrypt_fname_siphash(const struct inode *dir, const struct qstr *name)
|
|
|
|
{
|
|
|
|
const struct fscrypt_info *ci = dir->i_crypt_info;
|
|
|
|
|
|
|
|
WARN_ON(!ci->ci_dirhash_key_initialized);
|
|
|
|
|
|
|
|
return siphash(name->name, name->len, &ci->ci_dirhash_key);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(fscrypt_fname_siphash);
|
|
|
|
|
2019-12-09 20:43:59 +00:00
|
|
|
/*
|
|
|
|
* Validate dentries in encrypted directories to make sure we aren't potentially
|
|
|
|
* caching stale dentries after a key has been added.
|
|
|
|
*/
|
|
|
|
static int fscrypt_d_revalidate(struct dentry *dentry, unsigned int flags)
|
|
|
|
{
|
|
|
|
struct dentry *dir;
|
|
|
|
int err;
|
|
|
|
int valid;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Plaintext names are always valid, since fscrypt doesn't support
|
|
|
|
* reverting to ciphertext names without evicting the directory's inode
|
|
|
|
* -- which implies eviction of the dentries in the directory.
|
|
|
|
*/
|
|
|
|
if (!(dentry->d_flags & DCACHE_ENCRYPTED_NAME))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ciphertext name; valid if the directory's key is still unavailable.
|
|
|
|
*
|
|
|
|
* Although fscrypt forbids rename() on ciphertext names, we still must
|
|
|
|
* use dget_parent() here rather than use ->d_parent directly. That's
|
|
|
|
* because a corrupted fs image may contain directory hard links, which
|
|
|
|
* the VFS handles by moving the directory's dentry tree in the dcache
|
|
|
|
* each time ->lookup() finds the directory and it already has a dentry
|
|
|
|
* elsewhere. Thus ->d_parent can be changing, and we must safely grab
|
|
|
|
* a reference to some ->d_parent to prevent it from being freed.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (flags & LOOKUP_RCU)
|
|
|
|
return -ECHILD;
|
|
|
|
|
|
|
|
dir = dget_parent(dentry);
|
|
|
|
err = fscrypt_get_encryption_info(d_inode(dir));
|
|
|
|
valid = !fscrypt_has_encryption_key(d_inode(dir));
|
|
|
|
dput(dir);
|
|
|
|
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
return valid;
|
|
|
|
}
|
|
|
|
|
|
|
|
const struct dentry_operations fscrypt_d_ops = {
|
|
|
|
.d_revalidate = fscrypt_d_revalidate,
|
|
|
|
};
|