Message ID | 20171023214058.128121-1-ebiggers3@gmail.com |
---|---|
Headers | show
Return-Path: <linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133; helo=bombadil.infradead.org; envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=<UNKNOWN>) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZE+jyChD"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="csksw0gX"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3yLVK83Gh7z9sPt for <incoming@patchwork.ozlabs.org>; Tue, 24 Oct 2017 08:43:56 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=JJ8erj5zuC90buRl81oFcVX2eRvA1zVtSuf7N/TElig=; b=ZE+ jyChDQVYQgwNEExST+mmt1Szg9kopCyKiiK0OP29UqtTS4srkmESYp83XD5tDlAfNvC2207hNlR1+ zb9SdyFrEeR+3PoO70AVcvka79xJetv4/XpKZdS0eN4pRjrEquRyZpkEVmu74etyqC7MZa+mF+NnP VRjeyWDNIDZsjks9kcyzdS5WxfRapp80b6jWom2UqcHuwK+tCCBw5HY50YTNEYqQdtoWzGoEhHXkL DKNKe3pP3dTkwALOytydyfLuuZQ0dTpGBDPCfTlU0CGabSoTtBWcKNuw2Un/ay4ZWljYh8LPiUpez gCByFTnovh0cryv+OHWNwmS4fV+PWmw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1e6kVf-0005ms-Em; Mon, 23 Oct 2017 21:43:47 +0000 Received: from mail-io0-x244.google.com ([2607:f8b0:4001:c06::244]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1e6kUO-0004fF-2T for linux-mtd@lists.infradead.org; Mon, 23 Oct 2017 21:42:30 +0000 Received: by mail-io0-x244.google.com with SMTP id n137so21760521iod.6 for <linux-mtd@lists.infradead.org>; Mon, 23 Oct 2017 14:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=C6PzkAz48yU0/gQ6oyhZAuiAF4Iyv5P381UbWR2mvD4=; b=csksw0gXpxZZyHGDm1zkXVPwCmBmlJSJ8Nin9OHtGUPYQwuG9gXHT0gdh1gbULBxOi 2DuxlQjRNodZ5mTg3XzB+8NfTyVgAJY3hLirKJ7kypJ85AqRHXBImWEbg04jdNDaRUf1 mhPETIwQ49bwEpcWwGP+6b+Q7C50kZjP0NxWxqWlmDr/hiYIenPLOlFv4nQQocfBrpY1 rOZw6lrF55r2orcCxSib3vgHdLWq6r4E19OVmSb0sld4VkYoSd9uvGBP3KjtDFHhDSrO KOa1mJNVX/VC1TipHjfRf9XmrBLBlU2VxdptreTgAHFkftFxBZdHggU18tsTAOMNtU90 x09Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=C6PzkAz48yU0/gQ6oyhZAuiAF4Iyv5P381UbWR2mvD4=; b=q3jxctu8kWUrlQt54kAsAux4Xzgu4EQhapUe2D/51QgPo0nLqAzjHDRtCFTsR2p1+n pZuPrGKM44jq5X9PsYIlsx+vULGS/uG5Qp8w7qEs/iaZDdkQA50S5GrgsXUUVW8yv+M+ +fbHBmFhYyeQDfd57PbfVTW1M7ap2QoS+uHUTCA5X5/jaohW2HRAV20tWXK+MvqpdiSl kIg/S3SkQxLMdNfwFGhuxff05vEYeKFZ6iE34QAndWDROW3lE7eSqrkmWuTbmLF6B8Y8 I2FhrJoCwqbTYR+DApM746C0Zhgn1t3lFi9TQSS7gjd1p6/bznTvJ6wbOZR4Bu/ZGT8H t4Dg== X-Gm-Message-State: AMCzsaX9FJiPsj9wj52wF1EZ8FdWPIAV9GV8tC25AoQ67S/eWPp4oAgL ngXRN9Aw6xXDSfZPO4MeUGr3YA5D X-Google-Smtp-Source: ABhQp+Rb8yt8fYUIOZnCRdEgy10s2CueZQ3698ye+e3/a4Fg8vHv+qbBPLbkEqctnzH056/Ihd1QTQ== X-Received: by 10.107.12.170 with SMTP id 42mr20526645iom.268.1508794926988; Mon, 23 Oct 2017 14:42:06 -0700 (PDT) Received: from ebiggers-linuxstation.kir.corp.google.com ([100.66.175.88]) by smtp.gmail.com with ESMTPSA id i63sm3558482ioi.68.2017.10.23.14.42.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Oct 2017 14:42:05 -0700 (PDT) From: Eric Biggers <ebiggers3@gmail.com> To: linux-fscrypt@vger.kernel.org Subject: [RFC PATCH 00/25] fscrypt: filesystem-level keyring and v2 policy support Date: Mon, 23 Oct 2017 14:40:33 -0700 Message-Id: <20171023214058.128121-1-ebiggers3@gmail.com> X-Mailer: git-send-email 2.15.0.rc0.271.g36b669edcc-goog X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20171023_144228_195121_7771FCD3 X-CRM114-Status: GOOD ( 21.88 ) X-Spam-Score: -1.8 (-) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-1.8 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (ebiggers3[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ebiggers3[at]gmail.com) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org> List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-mtd>, <mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe> List-Archive: <http://lists.infradead.org/pipermail/linux-mtd/> List-Post: <mailto:linux-mtd@lists.infradead.org> List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help> List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>, <mailto:linux-mtd-request@lists.infradead.org?subject=subscribe> Cc: Ryo Hashimoto <hashimoto@chromium.org>, Gwendal Grignou <gwendal@chromium.org>, "Theodore Y . Ts'o" <tytso@mit.edu>, Eric Biggers <ebiggers@google.com>, linux-api@vger.kernel.org, Nick Desaulniers <ndesaulniers@google.com>, linux-f2fs-devel@lists.sourceforge.net, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, Michael Halcrow <mhalcrow@google.com>, Sarthak Kukreti <sarthakkukreti@chromium.org>, linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>, linux-ext4@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" <linux-mtd-bounces@lists.infradead.org> Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org |
Series |
fscrypt: filesystem-level keyring and v2 policy support
|
expand
|
From: Eric Biggers <ebiggers@google.com> Hello, This patchset solves multiple interrelated problems with how filesystem encryption keys are managed (for ext4, f2fs, and ubifs), including: (1) There is a visibility mismatch between the filesystem/VFS "view" of encrypted files (which is global) and the process-subscribed keyrings (which are not global). Relying on process-subscribed keyrings to provide the encryption keys on-demand makes it quite difficult to support even simple things like running 'sudo', if encrypted files need to be accessed. (2) There is no API to securely remove an encryption key, which should wipe all secret keys from memory and revert the encrypted files to their ciphertext "view". Many users want this, even to the extent that they're already working around it using the very bad hack of 'echo 2 > /proc/sys/vm/drop_caches', or alternatively hacking in an ioctl to drop caches for a specific filesystem. (3) The key derivation function (KDF) used to derive the per-file encryption keys is nonstandard and has a number of problems, such as being trivially reversible. We've wanted to replace it for some time now. (4) There is no verification that the correct master key was supplied. This is actually a security vulnerability, as it allows malicious local users to associate the wrong key with files to which they have *read-only* access. This patchset is based loosely on my earlier patchset "fscrypt: key verification and KDF improvement". However, while the earlier patchset solved problems (3) and (4) above, it ignored (1) and (2). Consequently, it ended up with a solution which probably would have had to be reworked when we also solved (1) and (2). For example, the 'key_hash' field was hacked on to the existing on-disk format just to solve (4), but really we need it a different way to solve (1) and (2) as well, at least for non-root users. There was also a filesystem-level key cache hacked on for caching the HMAC transforms for HKDF, but really it should be a real keyring which you can add and remove keys from, as we need that anyway for (1) and (2). By considering all the problems together we end up with a solution which should be simpler in the end, notwithstanding the length of this patchset. This patchset is organized as follows: - Patches 1-6 introduce a filesystem-level crypto keyring and a new ioctl, FS_IOC_ADD_ENCRYPTION_KEY, which adds a master encryption key to it. This solves problem (1) above, though initially only for use cases where a privileged process sets up the keys. Patch 20 will make it unprivileged in some cases. - Patches 7-10 add a new ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY, which removes a master encryption key from the filesystem-level crypto keyring. It also evicts the inodes which had been "unlocked" using the key. This solves problem (2) above, though initially only for use cases where a privileged process sets up the keys. Patch 20 will make it unprivileged in some cases. - Patch 11 adds an ioctl FS_IOC_GET_ENCRYPTION_KEY_STATUS which retrieves the status of a key in the filesystem-level crypto keyring. - Patches 12-14 wire up the above ioctls to ext4, f2fs, and ubifs. - Patches 15-25 introduce a new encryption policy version ("v2") where master_key_descriptor is replaced with master_key_identifier, which is a cryptographic hash of the master key. This allows opening the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY ioctls up to non-root users. In turn, this avoids any need to rely on the process-subscribed keyrings and encounter their visibility problems, and it allows non-root users to securely remove their encryption keys. I also take the opportunity to replace the AES-ECB-based KDF with HKDF-SHA512, which is also used to compute the master_key_identifier so that we pass the master key into only a single cryptographic primitive. Note that patches 1-14 can be reviewed (and potentially even merged) on their own, without patches 15-25. At just that point, the ioctls to manage filesystem-level keys will be usable for existing encrypted files, for privileged users only. However, to understand some of the decisions made when designing the ioctls, it will be helpful to see how the later patches extend the ioctls to also be usable for v2 encryption policies and by unprivileged users. Please review all API and on-disk format changes carefully, as we will be locked into them once merged. You can also get this patchset from git at: Repository: https://github.com/ebiggers/linux.git Branch: fscrypt-v2-policy-and-api_v1 It has received light testing. I've also made proof-of-concept changes to the 'fscrypt' userspace program to make it support v2 encryption policies and the filesystem-level keyring. You can find those userspace changes in git at: Repository: https://github.com/ebiggers/fscrypt.git Branch: v2-policy-support To make the 'fscrypt' userspace program use v2 policies for new encrypted directories, add "policy_version": "2" to /etc/fscrypt.conf within the "options" section. (Again: for now please consider the userspace changes proof-of-concept quality only! So far I've been focusing on the kernel changes.) It's intended that the other major users of filesystem-level encryption, including the Android and Chromium OS key management systems, will switch to the new API and encryption policy version as well. Eric Biggers (25): fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h> fscrypt: use FSCRYPT_ prefix for uapi constants fscrypt: use FSCRYPT_* definitions, not FS_* fscrypt: refactor finding and deriving key fs: add ->s_master_keys to struct super_block fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl fs/inode.c: export inode_lru_list_del() fs/inode.c: rename and export dispose_list() fs/dcache.c: add shrink_dcache_inode() fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl ext4 crypto: wire up new ioctls for managing encryption keys f2fs crypto: wire up new ioctls for managing encryption keys ubifs crypto: wire up new ioctls for managing encryption keys fscrypt: add UAPI definitions to get/set v2 encryption policies fscrypt: implement basic handling of v2 encryption policies fscrypt: add an HKDF-SHA512 implementation fscrypt: allow adding and removing keys for v2 encryption policies fscrypt: use HKDF-SHA512 to derive the per-file keys for v2 policies fscrypt: allow unprivileged users to add/remove keys for v2 policies fscrypt: require that key be added when setting a v2 encryption policy ext4 crypto: wire up FS_IOC_GET_ENCRYPTION_POLICY_EX f2fs crypto: wire up FS_IOC_GET_ENCRYPTION_POLICY_EX ubifs crypto: wire up FS_IOC_GET_ENCRYPTION_POLICY_EX fscrypt: document the new ioctls and policy version Documentation/filesystems/fscrypt.rst | 575 ++++++++++-- fs/crypto/Kconfig | 2 + fs/crypto/crypto.c | 19 +- fs/crypto/fname.c | 4 +- fs/crypto/fscrypt_private.h | 196 +++- fs/crypto/keyinfo.c | 1619 ++++++++++++++++++++++++++++++--- fs/crypto/policy.c | 373 +++++--- fs/dcache.c | 33 + fs/ext4/ioctl.c | 22 + fs/f2fs/file.c | 21 +- fs/inode.c | 24 +- fs/super.c | 3 + fs/ubifs/ioctl.c | 24 +- include/linux/dcache.h | 1 + include/linux/fs.h | 6 + include/linux/fscrypt.h | 12 +- include/linux/fscrypt_notsupp.h | 23 + include/linux/fscrypt_supp.h | 4 + include/uapi/linux/fs.h | 50 +- include/uapi/linux/fscrypt.h | 159 ++++ 20 files changed, 2724 insertions(+), 446 deletions(-) create mode 100644 include/uapi/linux/fscrypt.h