2019-05-19 06:08:55 -06:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2017-10-09 13:15:40 -06:00
|
|
|
/*
|
|
|
|
|
* fs/crypto/hooks.c
|
|
|
|
|
*
|
|
|
|
|
* Encryption hooks for higher-level filesystem operations.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "fscrypt_private.h"
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* fscrypt_file_open - prepare to open a possibly-encrypted regular file
|
|
|
|
|
* @inode: the inode being opened
|
|
|
|
|
* @filp: the struct file being set up
|
|
|
|
|
*
|
|
|
|
|
* Currently, an encrypted regular file can only be opened if its encryption key
|
|
|
|
|
* is available; access to the raw encrypted contents is not supported.
|
|
|
|
|
* Therefore, we first set up the inode's encryption key (if not already done)
|
|
|
|
|
* and return an error if it's unavailable.
|
|
|
|
|
*
|
|
|
|
|
* We also verify that if the parent directory (from the path via which the file
|
|
|
|
|
* is being opened) is encrypted, then the inode being opened uses the same
|
|
|
|
|
* encryption policy. This is needed as part of the enforcement that all files
|
|
|
|
|
* in an encrypted directory tree use the same encryption policy, as a
|
|
|
|
|
* protection against certain types of offline attacks. Note that this check is
|
|
|
|
|
* needed even when opening an *unencrypted* file, since it's forbidden to have
|
|
|
|
|
* an unencrypted file in an encrypted directory.
|
|
|
|
|
*
|
|
|
|
|
* Return: 0 on success, -ENOKEY if the key is missing, or another -errno code
|
|
|
|
|
*/
|
|
|
|
|
int fscrypt_file_open(struct inode *inode, struct file *filp)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
struct dentry *dir;
|
|
|
|
|
|
|
|
|
|
err = fscrypt_require_key(inode);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
dir = dget_parent(file_dentry(filp));
|
|
|
|
|
if (IS_ENCRYPTED(d_inode(dir)) &&
|
|
|
|
|
!fscrypt_has_permitted_context(d_inode(dir), inode)) {
|
2019-07-24 12:07:58 -06:00
|
|
|
fscrypt_warn(inode,
|
|
|
|
|
"Inconsistent encryption context (parent directory: %lu)",
|
|
|
|
|
d_inode(dir)->i_ino);
|
2017-10-09 13:15:40 -06:00
|
|
|
err = -EPERM;
|
|
|
|
|
}
|
|
|
|
|
dput(dir);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(fscrypt_file_open);
|
2017-10-09 13:15:41 -06:00
|
|
|
|
2019-03-20 12:39:10 -06:00
|
|
|
int __fscrypt_prepare_link(struct inode *inode, struct inode *dir,
|
|
|
|
|
struct dentry *dentry)
|
2017-10-09 13:15:41 -06:00
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = fscrypt_require_key(dir);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
fscrypt: add fscrypt_is_nokey_name()
commit 159e1de201b6fca10bfec50405a3b53a561096a8 upstream.
It's possible to create a duplicate filename in an encrypted directory
by creating a file concurrently with adding the encryption key.
Specifically, sys_open(O_CREAT) (or sys_mkdir(), sys_mknod(), or
sys_symlink()) can lookup the target filename while the directory's
encryption key hasn't been added yet, resulting in a negative no-key
dentry. The VFS then calls ->create() (or ->mkdir(), ->mknod(), or
->symlink()) because the dentry is negative. Normally, ->create() would
return -ENOKEY due to the directory's key being unavailable. However,
if the key was added between the dentry lookup and ->create(), then the
filesystem will go ahead and try to create the file.
If the target filename happens to already exist as a normal name (not a
no-key name), a duplicate filename may be added to the directory.
In order to fix this, we need to fix the filesystems to prevent
->create(), ->mkdir(), ->mknod(), and ->symlink() on no-key names.
(->rename() and ->link() need it too, but those are already handled
correctly by fscrypt_prepare_rename() and fscrypt_prepare_link().)
In preparation for this, add a helper function fscrypt_is_nokey_name()
that filesystems can use to do this check. Use this helper function for
the existing checks that fs/crypto/ does for rename and link.
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201118075609.120337-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-28 11:54:30 -07:00
|
|
|
/* ... in case we looked up no-key name before key was added */
|
|
|
|
|
if (fscrypt_is_nokey_name(dentry))
|
2019-03-20 12:39:10 -06:00
|
|
|
return -ENOKEY;
|
|
|
|
|
|
2017-10-09 13:15:41 -06:00
|
|
|
if (!fscrypt_has_permitted_context(dir, inode))
|
fscrypt: return -EXDEV for incompatible rename or link into encrypted dir
Currently, trying to rename or link a regular file, directory, or
symlink into an encrypted directory fails with EPERM when the source
file is unencrypted or is encrypted with a different encryption policy,
and is on the same mountpoint. It is correct for the operation to fail,
but the choice of EPERM breaks tools like 'mv' that know to copy rather
than rename if they see EXDEV, but don't know what to do with EPERM.
Our original motivation for EPERM was to encourage users to securely
handle their data. Encrypting files by "moving" them into an encrypted
directory can be insecure because the unencrypted data may remain in
free space on disk, where it can later be recovered by an attacker.
It's much better to encrypt the data from the start, or at least try to
securely delete the source data e.g. using the 'shred' program.
However, the current behavior hasn't been effective at achieving its
goal because users tend to be confused, hack around it, and complain;
see e.g. https://github.com/google/fscrypt/issues/76. And in some cases
it's actually inconsistent or unnecessary. For example, 'mv'-ing files
between differently encrypted directories doesn't work even in cases
where it can be secure, such as when in userspace the same passphrase
protects both directories. Yet, you *can* already 'mv' unencrypted
files into an encrypted directory if the source files are on a different
mountpoint, even though doing so is often insecure.
There are probably better ways to teach users to securely handle their
files. For example, the 'fscrypt' userspace tool could provide a
command that migrates unencrypted files into an encrypted directory,
acting like 'shred' on the source files and providing appropriate
warnings depending on the type of the source filesystem and disk.
Receiving errors on unimportant files might also force some users to
disable encryption, thus making the behavior counterproductive. It's
desirable to make encryption as unobtrusive as possible.
Therefore, change the error code from EPERM to EXDEV so that tools
looking for EXDEV will fall back to a copy.
This, of course, doesn't prevent users from still doing the right things
to securely manage their files. Note that this also matches the
behavior when a file is renamed between two project quota hierarchies;
so there's precedent for using EXDEV for things other than mountpoints.
xfstests generic/398 will require an update with this change.
[Rewritten from an earlier patch series by Michael Halcrow.]
Cc: Michael Halcrow <mhalcrow@google.com>
Cc: Joe Richey <joerichey@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-01-22 17:20:21 -07:00
|
|
|
return -EXDEV;
|
2017-10-09 13:15:41 -06:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(__fscrypt_prepare_link);
|
2017-10-09 13:15:42 -06:00
|
|
|
|
|
|
|
|
int __fscrypt_prepare_rename(struct inode *old_dir, struct dentry *old_dentry,
|
|
|
|
|
struct inode *new_dir, struct dentry *new_dentry,
|
|
|
|
|
unsigned int flags)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = fscrypt_require_key(old_dir);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
err = fscrypt_require_key(new_dir);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
fscrypt: add fscrypt_is_nokey_name()
commit 159e1de201b6fca10bfec50405a3b53a561096a8 upstream.
It's possible to create a duplicate filename in an encrypted directory
by creating a file concurrently with adding the encryption key.
Specifically, sys_open(O_CREAT) (or sys_mkdir(), sys_mknod(), or
sys_symlink()) can lookup the target filename while the directory's
encryption key hasn't been added yet, resulting in a negative no-key
dentry. The VFS then calls ->create() (or ->mkdir(), ->mknod(), or
->symlink()) because the dentry is negative. Normally, ->create() would
return -ENOKEY due to the directory's key being unavailable. However,
if the key was added between the dentry lookup and ->create(), then the
filesystem will go ahead and try to create the file.
If the target filename happens to already exist as a normal name (not a
no-key name), a duplicate filename may be added to the directory.
In order to fix this, we need to fix the filesystems to prevent
->create(), ->mkdir(), ->mknod(), and ->symlink() on no-key names.
(->rename() and ->link() need it too, but those are already handled
correctly by fscrypt_prepare_rename() and fscrypt_prepare_link().)
In preparation for this, add a helper function fscrypt_is_nokey_name()
that filesystems can use to do this check. Use this helper function for
the existing checks that fs/crypto/ does for rename and link.
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201118075609.120337-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-28 11:54:30 -07:00
|
|
|
/* ... in case we looked up no-key name(s) before key was added */
|
|
|
|
|
if (fscrypt_is_nokey_name(old_dentry) ||
|
|
|
|
|
fscrypt_is_nokey_name(new_dentry))
|
2019-03-20 12:39:10 -06:00
|
|
|
return -ENOKEY;
|
|
|
|
|
|
2017-10-09 13:15:42 -06:00
|
|
|
if (old_dir != new_dir) {
|
|
|
|
|
if (IS_ENCRYPTED(new_dir) &&
|
|
|
|
|
!fscrypt_has_permitted_context(new_dir,
|
|
|
|
|
d_inode(old_dentry)))
|
fscrypt: return -EXDEV for incompatible rename or link into encrypted dir
Currently, trying to rename or link a regular file, directory, or
symlink into an encrypted directory fails with EPERM when the source
file is unencrypted or is encrypted with a different encryption policy,
and is on the same mountpoint. It is correct for the operation to fail,
but the choice of EPERM breaks tools like 'mv' that know to copy rather
than rename if they see EXDEV, but don't know what to do with EPERM.
Our original motivation for EPERM was to encourage users to securely
handle their data. Encrypting files by "moving" them into an encrypted
directory can be insecure because the unencrypted data may remain in
free space on disk, where it can later be recovered by an attacker.
It's much better to encrypt the data from the start, or at least try to
securely delete the source data e.g. using the 'shred' program.
However, the current behavior hasn't been effective at achieving its
goal because users tend to be confused, hack around it, and complain;
see e.g. https://github.com/google/fscrypt/issues/76. And in some cases
it's actually inconsistent or unnecessary. For example, 'mv'-ing files
between differently encrypted directories doesn't work even in cases
where it can be secure, such as when in userspace the same passphrase
protects both directories. Yet, you *can* already 'mv' unencrypted
files into an encrypted directory if the source files are on a different
mountpoint, even though doing so is often insecure.
There are probably better ways to teach users to securely handle their
files. For example, the 'fscrypt' userspace tool could provide a
command that migrates unencrypted files into an encrypted directory,
acting like 'shred' on the source files and providing appropriate
warnings depending on the type of the source filesystem and disk.
Receiving errors on unimportant files might also force some users to
disable encryption, thus making the behavior counterproductive. It's
desirable to make encryption as unobtrusive as possible.
Therefore, change the error code from EPERM to EXDEV so that tools
looking for EXDEV will fall back to a copy.
This, of course, doesn't prevent users from still doing the right things
to securely manage their files. Note that this also matches the
behavior when a file is renamed between two project quota hierarchies;
so there's precedent for using EXDEV for things other than mountpoints.
xfstests generic/398 will require an update with this change.
[Rewritten from an earlier patch series by Michael Halcrow.]
Cc: Michael Halcrow <mhalcrow@google.com>
Cc: Joe Richey <joerichey@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-01-22 17:20:21 -07:00
|
|
|
return -EXDEV;
|
2017-10-09 13:15:42 -06:00
|
|
|
|
|
|
|
|
if ((flags & RENAME_EXCHANGE) &&
|
|
|
|
|
IS_ENCRYPTED(old_dir) &&
|
|
|
|
|
!fscrypt_has_permitted_context(old_dir,
|
|
|
|
|
d_inode(new_dentry)))
|
fscrypt: return -EXDEV for incompatible rename or link into encrypted dir
Currently, trying to rename or link a regular file, directory, or
symlink into an encrypted directory fails with EPERM when the source
file is unencrypted or is encrypted with a different encryption policy,
and is on the same mountpoint. It is correct for the operation to fail,
but the choice of EPERM breaks tools like 'mv' that know to copy rather
than rename if they see EXDEV, but don't know what to do with EPERM.
Our original motivation for EPERM was to encourage users to securely
handle their data. Encrypting files by "moving" them into an encrypted
directory can be insecure because the unencrypted data may remain in
free space on disk, where it can later be recovered by an attacker.
It's much better to encrypt the data from the start, or at least try to
securely delete the source data e.g. using the 'shred' program.
However, the current behavior hasn't been effective at achieving its
goal because users tend to be confused, hack around it, and complain;
see e.g. https://github.com/google/fscrypt/issues/76. And in some cases
it's actually inconsistent or unnecessary. For example, 'mv'-ing files
between differently encrypted directories doesn't work even in cases
where it can be secure, such as when in userspace the same passphrase
protects both directories. Yet, you *can* already 'mv' unencrypted
files into an encrypted directory if the source files are on a different
mountpoint, even though doing so is often insecure.
There are probably better ways to teach users to securely handle their
files. For example, the 'fscrypt' userspace tool could provide a
command that migrates unencrypted files into an encrypted directory,
acting like 'shred' on the source files and providing appropriate
warnings depending on the type of the source filesystem and disk.
Receiving errors on unimportant files might also force some users to
disable encryption, thus making the behavior counterproductive. It's
desirable to make encryption as unobtrusive as possible.
Therefore, change the error code from EPERM to EXDEV so that tools
looking for EXDEV will fall back to a copy.
This, of course, doesn't prevent users from still doing the right things
to securely manage their files. Note that this also matches the
behavior when a file is renamed between two project quota hierarchies;
so there's precedent for using EXDEV for things other than mountpoints.
xfstests generic/398 will require an update with this change.
[Rewritten from an earlier patch series by Michael Halcrow.]
Cc: Michael Halcrow <mhalcrow@google.com>
Cc: Joe Richey <joerichey@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-01-22 17:20:21 -07:00
|
|
|
return -EXDEV;
|
2017-10-09 13:15:42 -06:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(__fscrypt_prepare_rename);
|
2017-10-09 13:15:43 -06:00
|
|
|
|
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 12:39:13 -06:00
|
|
|
int __fscrypt_prepare_lookup(struct inode *dir, struct dentry *dentry,
|
|
|
|
|
struct fscrypt_name *fname)
|
2017-10-09 13:15:43 -06:00
|
|
|
{
|
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 12:39:13 -06:00
|
|
|
int err = fscrypt_setup_filename(dir, &dentry->d_name, 1, fname);
|
2017-10-09 13:15:43 -06:00
|
|
|
|
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 12:39:13 -06:00
|
|
|
if (err && err != -ENOENT)
|
2017-10-09 13:15:43 -06:00
|
|
|
return err;
|
|
|
|
|
|
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 12:39:13 -06:00
|
|
|
if (fname->is_ciphertext_name) {
|
2017-10-09 13:15:43 -06:00
|
|
|
spin_lock(&dentry->d_lock);
|
2019-03-20 12:39:09 -06:00
|
|
|
dentry->d_flags |= DCACHE_ENCRYPTED_NAME;
|
2017-10-09 13:15:43 -06:00
|
|
|
spin_unlock(&dentry->d_lock);
|
2019-03-20 12:39:12 -06:00
|
|
|
d_set_d_op(dentry, &fscrypt_d_ops);
|
2017-10-09 13:15:43 -06:00
|
|
|
}
|
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 12:39:13 -06:00
|
|
|
return err;
|
2017-10-09 13:15:43 -06:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(__fscrypt_prepare_lookup);
|
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 11:45:01 -07:00
|
|
|
|
|
|
|
|
int __fscrypt_prepare_symlink(struct inode *dir, unsigned int len,
|
|
|
|
|
unsigned int max_len,
|
|
|
|
|
struct fscrypt_str *disk_link)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* To calculate the size of the encrypted symlink target we need to know
|
|
|
|
|
* the amount of NUL padding, which is determined by the flags set in
|
|
|
|
|
* the encryption policy which will be inherited from the directory.
|
|
|
|
|
* The easiest way to get access to this is to just load the directory's
|
|
|
|
|
* fscrypt_info, since we'll need it to create the dir_entry anyway.
|
|
|
|
|
*
|
|
|
|
|
* Note: in test_dummy_encryption mode, @dir may be unencrypted.
|
|
|
|
|
*/
|
|
|
|
|
err = fscrypt_get_encryption_info(dir);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
if (!fscrypt_has_encryption_key(dir))
|
|
|
|
|
return -ENOKEY;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Calculate the size of the encrypted symlink and verify it won't
|
|
|
|
|
* exceed max_len. Note that for historical reasons, encrypted symlink
|
|
|
|
|
* targets are prefixed with the ciphertext length, despite this
|
|
|
|
|
* actually being redundant with i_size. This decreases by 2 bytes the
|
|
|
|
|
* longest symlink target we can accept.
|
|
|
|
|
*
|
|
|
|
|
* We could recover 1 byte by not counting a null terminator, but
|
|
|
|
|
* counting it (even though it is meaningless for ciphertext) is simpler
|
|
|
|
|
* for now since filesystems will assume it is there and subtract it.
|
|
|
|
|
*/
|
2018-01-11 21:30:08 -07:00
|
|
|
if (!fscrypt_fname_encrypted_size(dir, len,
|
|
|
|
|
max_len - sizeof(struct fscrypt_symlink_data),
|
|
|
|
|
&disk_link->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 11:45:01 -07:00
|
|
|
return -ENAMETOOLONG;
|
2018-01-11 21:30:08 -07:00
|
|
|
disk_link->len += sizeof(struct fscrypt_symlink_data);
|
|
|
|
|
|
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 11:45:01 -07:00
|
|
|
disk_link->name = NULL;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(__fscrypt_prepare_symlink);
|
|
|
|
|
|
|
|
|
|
int __fscrypt_encrypt_symlink(struct inode *inode, const char *target,
|
|
|
|
|
unsigned int len, struct fscrypt_str *disk_link)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
2018-01-19 14:45:24 -07:00
|
|
|
struct qstr iname = QSTR_INIT(target, 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 11:45:01 -07:00
|
|
|
struct fscrypt_symlink_data *sd;
|
|
|
|
|
unsigned int ciphertext_len;
|
|
|
|
|
|
|
|
|
|
err = fscrypt_require_key(inode);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
|
|
|
|
|
if (disk_link->name) {
|
|
|
|
|
/* filesystem-provided buffer */
|
|
|
|
|
sd = (struct fscrypt_symlink_data *)disk_link->name;
|
|
|
|
|
} else {
|
|
|
|
|
sd = kmalloc(disk_link->len, GFP_NOFS);
|
|
|
|
|
if (!sd)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
ciphertext_len = disk_link->len - sizeof(*sd);
|
|
|
|
|
sd->len = cpu_to_le16(ciphertext_len);
|
|
|
|
|
|
2018-01-11 21:30:08 -07:00
|
|
|
err = fname_encrypt(inode, &iname, sd->encrypted_path, ciphertext_len);
|
2019-04-10 14:21:15 -06:00
|
|
|
if (err)
|
|
|
|
|
goto err_free_sd;
|
|
|
|
|
|
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 11:45:01 -07:00
|
|
|
/*
|
|
|
|
|
* Null-terminating the ciphertext doesn't make sense, but we still
|
|
|
|
|
* count the null terminator in the length, so we might as well
|
|
|
|
|
* initialize it just in case the filesystem writes it out.
|
|
|
|
|
*/
|
|
|
|
|
sd->encrypted_path[ciphertext_len] = '\0';
|
|
|
|
|
|
2019-04-10 14:21:15 -06:00
|
|
|
/* Cache the plaintext symlink target for later use by get_link() */
|
|
|
|
|
err = -ENOMEM;
|
|
|
|
|
inode->i_link = kmemdup(target, len + 1, GFP_NOFS);
|
|
|
|
|
if (!inode->i_link)
|
|
|
|
|
goto err_free_sd;
|
|
|
|
|
|
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 11:45:01 -07:00
|
|
|
if (!disk_link->name)
|
|
|
|
|
disk_link->name = (unsigned char *)sd;
|
|
|
|
|
return 0;
|
2019-04-10 14:21:15 -06:00
|
|
|
|
|
|
|
|
err_free_sd:
|
|
|
|
|
if (!disk_link->name)
|
|
|
|
|
kfree(sd);
|
|
|
|
|
return err;
|
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 11:45:01 -07:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(__fscrypt_encrypt_symlink);
|
2018-01-05 11:45:02 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* fscrypt_get_symlink - get the target of an encrypted symlink
|
|
|
|
|
* @inode: the symlink inode
|
|
|
|
|
* @caddr: the on-disk contents of the symlink
|
|
|
|
|
* @max_size: size of @caddr buffer
|
2019-04-10 14:21:15 -06:00
|
|
|
* @done: if successful, will be set up to free the returned target if needed
|
2018-01-05 11:45:02 -07:00
|
|
|
*
|
|
|
|
|
* If the symlink's encryption key is available, we decrypt its target.
|
|
|
|
|
* Otherwise, we encode its target for presentation.
|
|
|
|
|
*
|
|
|
|
|
* This may sleep, so the filesystem must have dropped out of RCU mode already.
|
|
|
|
|
*
|
|
|
|
|
* Return: the presentable symlink target or an ERR_PTR()
|
|
|
|
|
*/
|
|
|
|
|
const char *fscrypt_get_symlink(struct inode *inode, const void *caddr,
|
|
|
|
|
unsigned int max_size,
|
|
|
|
|
struct delayed_call *done)
|
|
|
|
|
{
|
|
|
|
|
const struct fscrypt_symlink_data *sd;
|
|
|
|
|
struct fscrypt_str cstr, pstr;
|
2019-04-10 14:21:15 -06:00
|
|
|
bool has_key;
|
2018-01-05 11:45:02 -07:00
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
/* This is for encrypted symlinks only */
|
|
|
|
|
if (WARN_ON(!IS_ENCRYPTED(inode)))
|
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
2019-04-10 14:21:15 -06:00
|
|
|
/* If the decrypted target is already cached, just return it. */
|
|
|
|
|
pstr.name = READ_ONCE(inode->i_link);
|
|
|
|
|
if (pstr.name)
|
|
|
|
|
return pstr.name;
|
|
|
|
|
|
2018-01-05 11:45:02 -07:00
|
|
|
/*
|
|
|
|
|
* Try to set up the symlink's encryption key, but we can continue
|
|
|
|
|
* regardless of whether the key is available or not.
|
|
|
|
|
*/
|
|
|
|
|
err = fscrypt_get_encryption_info(inode);
|
|
|
|
|
if (err)
|
|
|
|
|
return ERR_PTR(err);
|
2019-04-10 14:21:15 -06:00
|
|
|
has_key = fscrypt_has_encryption_key(inode);
|
2018-01-05 11:45:02 -07:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* For historical reasons, encrypted symlink targets are prefixed with
|
|
|
|
|
* the ciphertext length, even though this is redundant with i_size.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
if (max_size < sizeof(*sd))
|
|
|
|
|
return ERR_PTR(-EUCLEAN);
|
|
|
|
|
sd = caddr;
|
|
|
|
|
cstr.name = (unsigned char *)sd->encrypted_path;
|
|
|
|
|
cstr.len = le16_to_cpu(sd->len);
|
|
|
|
|
|
|
|
|
|
if (cstr.len == 0)
|
|
|
|
|
return ERR_PTR(-EUCLEAN);
|
|
|
|
|
|
|
|
|
|
if (cstr.len + sizeof(*sd) - 1 > max_size)
|
|
|
|
|
return ERR_PTR(-EUCLEAN);
|
|
|
|
|
|
|
|
|
|
err = fscrypt_fname_alloc_buffer(inode, cstr.len, &pstr);
|
|
|
|
|
if (err)
|
|
|
|
|
return ERR_PTR(err);
|
|
|
|
|
|
|
|
|
|
err = fscrypt_fname_disk_to_usr(inode, 0, 0, &cstr, &pstr);
|
|
|
|
|
if (err)
|
|
|
|
|
goto err_kfree;
|
|
|
|
|
|
|
|
|
|
err = -EUCLEAN;
|
|
|
|
|
if (pstr.name[0] == '\0')
|
|
|
|
|
goto err_kfree;
|
|
|
|
|
|
|
|
|
|
pstr.name[pstr.len] = '\0';
|
2019-04-10 14:21:15 -06:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Cache decrypted symlink targets in i_link for later use. Don't cache
|
|
|
|
|
* symlink targets encoded without the key, since those become outdated
|
|
|
|
|
* once the key is added. This pairs with the READ_ONCE() above and in
|
|
|
|
|
* the VFS path lookup code.
|
|
|
|
|
*/
|
|
|
|
|
if (!has_key ||
|
|
|
|
|
cmpxchg_release(&inode->i_link, NULL, pstr.name) != NULL)
|
|
|
|
|
set_delayed_call(done, kfree_link, pstr.name);
|
|
|
|
|
|
2018-01-05 11:45:02 -07:00
|
|
|
return pstr.name;
|
|
|
|
|
|
|
|
|
|
err_kfree:
|
|
|
|
|
kfree(pstr.name);
|
|
|
|
|
return ERR_PTR(err);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(fscrypt_get_symlink);
|