• Eric Biggers's avatar
    fscrypt: fix context consistency check when key(s) unavailable · eb86b4c6
    Eric Biggers authored
    commit 272f98f6 upstream.
    
    To mitigate some types of offline attacks, filesystem encryption is
    designed to enforce that all files in an encrypted directory tree use
    the same encryption policy (i.e. the same encryption context excluding
    the nonce).  However, the fscrypt_has_permitted_context() function which
    enforces this relies on comparing struct fscrypt_info's, which are only
    available when we have the encryption keys.  This can cause two
    incorrect behaviors:
    
    1. If we have the parent directory's key but not the child's key, or
       vice versa, then fscrypt_has_permitted_context() returned false,
       causing applications to see EPERM or ENOKEY.  This is incorrect if
       the encryption contexts are in fact consistent.  Although we'd
       normally have either both keys or neither key in that case since the
       master_key_descriptors would be the same, this is not guaranteed
       because keys can be added or removed from keyrings at any time.
    
    2. If we have neither the parent's key nor the child's key, then
       fscrypt_has_permitted_context() returned true, causing applications
       to see no error (or else an error for some other reason).  This is
       incorrect if the encryption contexts are in fact inconsistent, since
       in that case we should deny access.
    
    To fix this, retrieve and compare the fscrypt_contexts if we are unable
    to set up both fscrypt_infos.
    
    While this slightly hurts performance when accessing an encrypted
    directory tree without the key, this isn't a case we really need to be
    optimizing for; access *with* the key is much more important.
    Furthermore, the performance hit is barely noticeable given that we are
    already retrieving the fscrypt_context and doing two keyring searches in
    fscrypt_get_encryption_info().  If we ever actually wanted to optimize
    this case we might start by caching the fscrypt_contexts.
    Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
    Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    eb86b4c6
policy.c 8.51 KB