From patchwork Tue Apr 18 21:06:42 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gwendal Grignou X-Patchwork-Id: 751998 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3w6yPN71RXz9s3w for ; Wed, 19 Apr 2017 07:07:04 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="mNdeWdA+"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753045AbdDRVHA (ORCPT ); Tue, 18 Apr 2017 17:07:00 -0400 Received: from mail-pf0-f172.google.com ([209.85.192.172]:33424 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751678AbdDRVG7 (ORCPT ); Tue, 18 Apr 2017 17:06:59 -0400 Received: by mail-pf0-f172.google.com with SMTP id a188so2208786pfa.0 for ; Tue, 18 Apr 2017 14:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:from:to:cc:subject:date:message-id; bh=iDSVQeIN2oGDYRq42Wo/XvgscJ9AaZo/8mP3H1SeX5A=; b=mNdeWdA+bbzZAvtEov5aJXRCoEbzM8t28m0ogSTMcsSU3rFGGvj19e4NYPzvtdFrAv Dam55bTzfpvPAFZ8DAjNyzRLTqBM+Q5M96digEziF2KBK3Un4XDVAxuDnvx2TMpOqtGX HvtvwJuEAehLM7pLss459VCEh6NaPTG/5duvLD35jyQutzUIWlrKKhmI4718L+OWKf70 poWIwVZpOFcwG7joXJJ7ZZIFKHl7i60uBH6E9A+ueXjlMSZ7r3y1DS6dIPPsqyX6sTiS Wgpt9l43skzMfAdX4eRYE8CH4ooCcVACoTaLvcAyEOq5CcL1UAGrTrCFwD560KloRv/5 RfBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id; bh=iDSVQeIN2oGDYRq42Wo/XvgscJ9AaZo/8mP3H1SeX5A=; b=heKfCC8amdBTzNS+jpLKz1OKVi6WGp1AibIMDeO1nooR1RbioaFvFGH0Y9ktq6YuYI 5RkbYz/SsIjIMHbUpvxNiGdp1xUs74XSqczXSYHb6iLBJ0Q5sJYIQgXZuXq8E4AuLLzA 5aZKU264kBglHBkQO/MU7e/kYxjcBxvMPhXObYBd54x+pBtGrkSoWq9In+/gRZd9eEKn cv5wpI8yiCOqL72olABZXxJFShe1q+h+MJa3qcSzZjgI2XdfCqHCLEiPkjvNAi6tYsLQ hq27wmZkEbMZO7DMeSUudTuxkf7qrELS02wNZXTpogY0+7J81LKqVMAN/B7ggjnNda5F 6MOA== X-Gm-Message-State: AN3rC/5S1+yHpnnR30zu61pS+AAGFiaXIkXVWHaeD5psvwCEzT4zQjnL TQI79VuGJbWWfRDB X-Received: by 10.98.252.142 with SMTP id e136mr6817653pfh.241.1492549618186; Tue, 18 Apr 2017 14:06:58 -0700 (PDT) Received: from gwendal.mtv.corp.google.com ([172.22.64.242]) by smtp.gmail.com with ESMTPSA id 73sm287842pfj.31.2017.04.18.14.06.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Apr 2017 14:06:57 -0700 (PDT) From: Gwendal Grignou To: tytso@mit.edu, ebiggers@google.com Cc: linux-ext4@vger.kernel.org, linux-fscrypt@vger.kernel.org, kinaba@chromium.org, hashimoto@chromium.org Subject: [PATCH] fscrypt: use 32 bytes of encrypted filename Date: Tue, 18 Apr 2017 14:06:42 -0700 Message-Id: <20170418210642.6039-1-gwendal@chromium.org> X-Mailer: git-send-email 2.12.2.816.g2cccc81164-goog Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org If we use only 16 bytes, due to how CBC works, if the names have the same beginning, their last ciphertext block (16 bytes) may be identical. It happens when two file names share the first 16k bytes and both have length withn 16 * n + 13 and 16 * n + 16. Instead use 32 bytes to build the filenames from encrypted data when directory is scrambled. The drawback is the scrambled filenames change after applying the patch. Consider an encrypted directory with: ls -il total 8 1177380 -rw-r--r--. 1 root root 0 Apr 18 12:10 system@framework@boot-telephony-common.art.crc 1177379 -rw-r--r--. 1 root root 0 Apr 18 12:10 system@framework@boot-telephony-common.oat.crc Once the key is invalidated, without the patch, ls -li produces: 1177379 -rw-r--r--. 1 root root 0 Apr 18 12:10 _a1Psh01n8FdhC8s9pUywlAyFzlz7n6C3 1177379 -rw-r--r--. 1 root root 0 Apr 18 12:10 _wJS,0akq14ehC8s9pUywlAyFzlz7n6C3 Both files show with the same inode. After the patch, the names are different, but the inode information is now correct: ls -li 1177380 -rw-r--r--. 1 root root 0 Apr 18 12:10 _a1Psh01n8FtxbeglW8BqhuthSUxMqh6cFKwz2nSJDXCIXMXOvfqLcD 1177379 -rw-r--r--. 1 root root 0 Apr 18 12:10 _wJS,0akq14eJcuQks7f2Vsg,zE0Jdz98FKwz2nSJDXCIXMXOvfqLcD Tested only on ext4. Signed-off-by: Gwendal Grignou --- Script to reproduce the error: BASE_DIR="~/" DIR="${BASE_DIR}/tmp" # Create directory. mkdir -p "${DIR}" echo foobar | e4crypt add_key "${DIR}" # Fill directory. cd "${DIR}" touch system@framework@boot-telephony-common.oat.crc touch system@framework@boot-telephony-common.art.crc cd .. # Check files have different inode. ls -il "${DIR}" # Invalidate key KEY="$(keyctl show | grep $(e4crypt get_policy "${DIR}" | cut -d ':' -f 2) | sed -ne 's/\(.*\) --al.*/\1/p')" sync keyctl invalidate "${KEY}" echo 3 > /proc/sys/vm/drop_caches # Once the key is invalidated, both files have the same inode: ls -il "${DIR}" if [ $(ls -i1 "${DIR}" | cut -d ' ' -f 1 | uniq | wc -l) -eq 1 ] ; then echo same inode! fi # if we try to remove the directory, we will get an error # : Structure needs cleaning # rm -rf "${DIR}" fs/crypto/fname.c | 20 +++++++++++++------- fs/ext4/namei.c | 4 ++-- 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c index 80bb956e14e5..71ddc3eaa62d 100644 --- a/fs/crypto/fname.c +++ b/fs/crypto/fname.c @@ -274,7 +274,7 @@ int fscrypt_fname_disk_to_usr(struct inode *inode, struct fscrypt_str *oname) { const struct qstr qname = FSTR_TO_QSTR(iname); - char buf[24]; + char buf[FS_FNAME_CRYPTO_DIGEST_SIZE + sizeof(u64)]; if (fscrypt_is_dot_dotdot(&qname)) { oname->name[0] = '.'; @@ -295,14 +295,19 @@ int fscrypt_fname_disk_to_usr(struct inode *inode, return 0; } if (hash) { - memcpy(buf, &hash, 4); - memcpy(buf + 4, &minor_hash, 4); + memcpy(buf, &hash, sizeof(u32)); + memcpy(buf + 4, &minor_hash, sizeof(u32)); } else { memset(buf, 0, 8); } - memcpy(buf + 8, iname->name + iname->len - 16, 16); + memcpy(buf + sizeof(u64), + iname->name + iname->len - FS_FNAME_CRYPTO_DIGEST_SIZE, + FS_FNAME_CRYPTO_DIGEST_SIZE); oname->name[0] = '_'; - oname->len = 1 + digest_encode(buf, 24, oname->name + 1); + oname->len = 1 + digest_encode( + buf, + FS_FNAME_CRYPTO_DIGEST_SIZE + sizeof(u64), + oname->name + 1); return 0; } EXPORT_SYMBOL(fscrypt_fname_disk_to_usr); @@ -375,10 +380,11 @@ int fscrypt_setup_filename(struct inode *dir, const struct qstr *iname, */ if (iname->name[0] == '_') bigname = 1; - if ((bigname && (iname->len != 33)) || (!bigname && (iname->len > 43))) + if ((bigname && iname->len != 55) || (!bigname && (iname->len > 43))) return -ENOENT; - fname->crypto_buf.name = kmalloc(32, GFP_KERNEL); + fname->crypto_buf.name = kmalloc( + FS_FNAME_CRYPTO_DIGEST_SIZE + sizeof(u64), GFP_KERNEL); if (fname->crypto_buf.name == NULL) return -ENOMEM; diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index c4a389a6027b..14b2a2335a32 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1257,8 +1257,8 @@ static inline int ext4_match(struct ext4_filename *fname, int ret; if (de->name_len < 16) return 0; - ret = memcmp(de->name + de->name_len - 16, - fname->crypto_buf.name + 8, 16); + ret = memcmp(de->name + de->name_len - 32, + fname->crypto_buf.name + 8, 32); return (ret == 0) ? 1 : 0; } name = fname->crypto_buf.name;