[RFC,06/25] fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl

From: Eric Biggers <ebiggers@google.com>

From: Eric Biggers <ebiggers@google.com>

Add a new filesystem encryption ioctl, FS_IOC_ADD_ENCRYPTION_KEY.  This
ioctl adds a master encryption key to the filesystem encryption keyring
->s_master_keys.

When a process tries to access an encrypted file that has not yet been
"unlocked" (set up with an ->i_crypt_info containing a crypto transform
keyed by the file's derived key), fscrypt_get_encryption_info() will
search for the master key in ->s_master_keys before falling back to the
process-subscribed keyrings.

For now this ioctl is root-only, which is necessary in part because the
keys are identified by master_key_descriptor, which is not
cryptographically tied to the actual key payload.  However, a later
patch will introduce a new encryption policy version where the key is
identified by a cryptographic hash.  This will, in combination with
other protections, make it possible for non-root users to use this ioctl
in some situations.

Why we need this
~~~~~~~~~~~~~~~~

The main problem is that the "locked/unlocked" (ciphertext/plaintext)
status of encrypted files is global, but currently the master keys are
not.  We only look for master keys in the process-subscribed keyrings;
that is, the current thread keyring, process keyring, and session
keyring, where the session keyring usually contains the user keyring.
This means we have to put the master keys in the keyrings for individual
users or for individual sessions.  This causes much confusion as soon as
a process with a different UID, such as a 'sudo' command, tries to
access encrypted files.  In such a situation, whether each individual
inode appears "locked" or "unlocked" will depend on whether it was
previously accessed and happens to still be in the inode cache, which is
more or less nondeterministic.

It may seem that we should indeed provide each process its own "view" of
the filesystem depending on whether it "has the key" or not.  However
that would be extremely difficult to do without a separate mount, due to
the way the VFS caches work.  Furthermore, it is actually missing the
point of encryption because it would *not* be encryption that would
provide the different "views", but rather kernel *code*.  Thus, it would
simply be an access control mechanism largely redundant with the many
existing access control mechanisms such as UNIX file permissions and
LSMs.  The reality is that the confidentially of encrypted files *after
the kernel already has the encryption key in memory* is only protected
by the correctness of the kernel, not by the mathematical properties of
encryption.

And at the end of the day, almost all users of filesystem encryption we
are aware of do really need the global view, because they need encrypted
files to be accessible to processes running under different UIDs.  This
can be as simple as needing to be able to run 'sudo', or it can be
something more complex like Android's key management system where
applications running under different UIDs as well as system processes
need access to the same encrypted files.

As a result, some very ugly hacks have been added to try to emulate
globally visible keys.  The Android and Chromium OS key management
systems simply create a "session" keyring in PID 1 and put all the keys
in it, which abuses the "session" keyring to have nothing to do with a
"session", but rather be a global keyring.  This is fragile, as it means
that the "session" keyring must never be changed.  There have also been
bugs involving processes that were forked before the "session" keyring
was created, causing them to miss out on the keys.

Meanwhile, filesystem encryption tools written for general-purpose Linux
distributions have no such ability to abuse the "session" keyring.  They
instead must implement "interesting" workarounds such as linking all the
user keyrings into root's user keyring, as is done by the fscrypt
userspace tool (see the design document at https://goo.gl/55cCrI).  This
raises security concerns, to say the least.

By having an API to add a key to the *filesystem* we'll be able to
eliminate all the above hacks and better express the intended semantics:
the "locked/unlocked" status of an encrypted directory is global.  And
orthogonally to encryption, existing mechanisms such as file permissions
and LSMs can and should continue to be used for the purpose of *access
control*.

Why use a custom key type
~~~~~~~~~~~~~~~~~~~~~~~~~

The keys the new ioctl adds to ->s_master_keys are still "keys" in the
sense of the keyrings service, but they have a custom key type rather
than the "logon" key type we currently require when userspace provides a
key via a process-subscribed keyring.

Judging just from this patch alone, the "logon" key type would be
sufficient.  However, later patches will be solving problems such as the
nonstandard KDF and the lack of a key removal API.  The solutions for
these problems will require tracking information on a per-master-key
basis.  Therefore, we'll need a custom structure associated with each
master key anyway.  A custom key type lets us do that easily.

Why not use add_key()
~~~~~~~~~~~~~~~~~~~~~

Instead of adding a new ioctl() to add a key, we could have userspace
use the add_key() system call.  In combination with an ioctl which
retrieves the key ID of ->s_master_keys, add_key() could be used to add
a key to ->s_master_keys.  Alternatively, we could add the concept of a
"global keyring" or "namespace keyring" to the keyrings service, where
that keyring would be searched in addition to the process-subscribed
keyrings.  Then, add_key() could add a key to that.

This actually makes sense given only the present patch.  However,
unfortunately it falls apart once we consider the follow-on changes.

First, we also need to add the ability to remove an encryption key, and
it will need to have more specialized semantics than keyctl_unlink() or
keyctl_revoke() can provide.  For example, we must not only wipe the
master key *secret* from memory, but we must also try to evict all the
inodes which had been "unlocked" using the key.  And it's possible that
even though the master key secret was wiped, some inodes could not be
evicted, since they may be busy.  In that case, we still want to wipe
the master key *secret* so that no more encrypted files can be
"unlocked".  But we also want to allow userspace to retry the request
later, so that evicting the remaining inodes can be re-attempted.
Alternatively, we want the same list of inodes to be picked up again if
the secret happens to be added again.  Trying to shoehorn these specific
semantics into the keyrings API would be very difficult.

Later we also want to open up the add/remove key operations to non-root
users by taking advantage of a new encryption policy version which
includes a cryptographic hash of the master key.  This is needed because
otherwise we wouldn't be able to fully replace the process-subscribed
keyrings and avoid all its problems mentioned earlier.  But to actually
make non-root use secure, we'll need to do some extra accounting where
we keep track of all users who have added a given key, then only really
remove a key after all users have removed it.  Non-root users also
cannot simply be given write permission to a global keyring.  So again,
it seems that trying to shoehorn the needed semantics into the keyrings
API would just create problems.

Nevertheless, we do still use the keyrings service internally so that we
reuse some code and get some "free" functionality such as having the
keys show up in /proc/keys for debugging purposes.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 fs/crypto/crypto.c              |  12 +-
 fs/crypto/fscrypt_private.h     |   3 +
 fs/crypto/keyinfo.c             | 351 +++++++++++++++++++++++++++++++++++++++-
 include/linux/fscrypt_notsupp.h |   5 +
 include/linux/fscrypt_supp.h    |   1 +
 include/uapi/linux/fscrypt.h    |  41 +++--
 6 files changed, 397 insertions(+), 16 deletions(-)

[RFC,06/25] fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl

Commit Message

Comments

Patch