[RFC,10/25] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl

From: Eric Biggers <ebiggers@google.com>

From: Eric Biggers <ebiggers@google.com>

Problem
~~~~~~~

Many filesystem encryption users want the ability to remove encryption
keys, causing the corresponding encrypted directories to appear "locked"
(presented in ciphertext form) again.  Moreover, users want removing an
encryption key to *really* remove it, in the sense that the removed keys
cannot be recovered even if kernel memory is compromised, e.g. by the
exploit of a kernel security vulnerability or by a physical attack.
This is desirable after a user logs out of the system, for example.  In
many cases users even already assume this to be the case and are
surprised to hear when it's not.

It is *not* sufficient to simply unlink the master key from the keyring
(or to revoke or invalidate it), since files are encrypted with per-file
keys instead of with the master keys directly.  Therefore, to really
remove a key we must also remove the per-file keys, e.g. by evicting the
corresponding inodes from the inode cache.  This also would have the
benefit of making encrypted files appear "locked" again.

Currently the workaround is to run:

    sync
    echo 2 > /proc/sys/vm/drop_caches

This is a very bad solution because it evicts all not-in-use inodes in
the system rather than just the inodes associated with the key being
removed.  Moreover, it requires root privileges, so non-root users
cannot lock their encrypted directories.  Finally, the drop_caches
sysctl was originally meant for debugging purposes only.

Nevertheless, the largest users of filesystem encryption (Android and
Chromium OS) actually want this capability badly enough that they are
actually using the drop_caches workaround.  Similarly, the drop_caches
workaround is also used in the PAM module provided by the fscrypt
userspace tool (https://github.com/google/fscrypt).  Needless to say,
this is causing significant performance problems due to inodes for
unencrypted system files being evicted.  So a real solution is needed.

Solution
~~~~~~~~

To properly solve this problem, we need an API which removes and wipes
the given master key, *and* removes and and wipes the corresponding
per-file keys.  This requires tracking which inodes have been "unlocked"
using each master key.  Originally that was not possible because the
kernel didn't actually have a centralized notion of what a master key
even was.  But now that we have the filesystem-level keyring
->s_master_keys it is finally possible.

Add this API as a new ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY.  It is the
counterpart of FS_IOC_ADD_ENCRYPTION_KEY.

FS_IOC_REMOVE_ENCRYPTION_KEY first wipes the master key's secret from
memory.  Then, it syncs the filesystem and tries to evict the list of
inodes that had been "unlocked" with the key.  Evicting the inodes has
several effects, including:

- The actual keys used to encrypt the data (in ->i_crypt_info->ci_ctfm)
  are wiped from memory.  Thus, they can no longer be recovered, even if
  kernel memory is later compromised.

- The encrypted files and directories once again appear "locked", i.e.
  in ciphertext or in "encrypted" form.  This is highly desirable from a
  user interface perspective.  It can also be desirable from a security
  perspective (although sometimes for the wrong reasons!).

- The pagecache pages are freed, which allows the plaintext file
  contents to be overwritten in memory later as the system continues
  running.  Currently we do not actually wipe the pages on free, nor
  does the kernel more generally wipe memory on free either.  Thus, for
  now we tolerate that an attacker who later gains access to kernel
  memory may be able to see portions of file contents and file names in
  plaintext in unallocated memory.  Security-conscious users who do not
  mind a performance hit may ameliorate this by enabling page poisoning.

Of course, some inodes may still be in use when a master key is removed,
and we cannot simply revoke random file descriptors, mmap's, etc.  The
approach we take is to skip in-use inodes, and notify userspace by
returning -EBUSY if any inodes could not be evicted.  Still, even in
this case the master key secret is removed, so no more files can be
unlocked with it.  Moreover, most of the inodes should still be evicted
as well.  Userspace can then retry the ioctl later to evict the
remaining inodes.  Alternatively, if userspace adds the key again, then
the refreshed secret will be associated with the existing list of inodes
so that they are correctly tracked for future key removals.

For now, FS_IOC_REMOVE_ENCRYPTION_KEY has to be restricted to privileged
users only, just like FS_IOC_ADD_ENCRYPTION_KEY.  This is sufficient for
use cases where all encryption keys are managed by a privileged process,
e.g. as is the case on Android and Chromium OS.

But in the more general case, non-root users need to be able to both
unlock *and* lock their own encrypted directories.  As it turns out, we
will indeed be able to support this through these ioctls, but non-root
use will need to be tied to the use of a new encryption policy version
which identifies the master key using a cryptographic hash.  (See later
patches.)

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 fs/crypto/fscrypt_private.h     |  18 ++-
 fs/crypto/keyinfo.c             | 347 ++++++++++++++++++++++++++++++++++++++--
 fs/crypto/policy.c              |   5 +-
 include/linux/fscrypt_notsupp.h |   6 +
 include/linux/fscrypt_supp.h    |   1 +
 include/uapi/linux/fscrypt.h    |   7 +
 6 files changed, 367 insertions(+), 17 deletions(-)

[RFC,10/25] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl

Commit Message

Patch