From patchwork Thu Jun 13 00:43:27 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jaskaran Singh Khurana X-Patchwork-Id: 10994673 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3C4D214DB for ; Fri, 14 Jun 2019 08:18:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3121827DCD for ; Fri, 14 Jun 2019 08:18:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2558027F8E; Fri, 14 Jun 2019 08:18:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id AFACC27E71 for ; Fri, 14 Jun 2019 08:18:31 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EBB9F85541; Fri, 14 Jun 2019 08:18:15 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C918766D44; Fri, 14 Jun 2019 08:18:14 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 96DF21833006; Fri, 14 Jun 2019 08:18:12 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x5D0iEDp018011 for ; Wed, 12 Jun 2019 20:44:16 -0400 Received: by smtp.corp.redhat.com (Postfix) id C29381001B18; Thu, 13 Jun 2019 00:44:14 +0000 (UTC) Delivered-To: dm-devel@redhat.com Received: from mx1.redhat.com (ext-mx12.extmail.prod.ext.phx2.redhat.com [10.5.110.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CBE561001B14; Thu, 13 Jun 2019 00:44:05 +0000 (UTC) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx1.redhat.com (Postfix) with ESMTP id 141C53079B9D; Thu, 13 Jun 2019 00:43:45 +0000 (UTC) Received: from jaskaran-Intel-Server-Board-S1200V3RPS-UEFI-Development-Kit.corp.microsoft.com (unknown [131.107.160.238]) by linux.microsoft.com (Postfix) with ESMTPSA id 380F620B7186; Wed, 12 Jun 2019 17:43:37 -0700 (PDT) From: Jaskaran Khurana To: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-fsdevel@vger.kernel.org Date: Wed, 12 Jun 2019 17:43:27 -0700 Message-Id: <20190613004328.4274-1-jaskarankhurana@linux.microsoft.com> X-Greylist: Sender passed SPF test, ACL 242 matched, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Thu, 13 Jun 2019 00:43:56 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Thu, 13 Jun 2019 00:43:56 +0000 (UTC) for IP:'13.77.154.182' DOMAIN:'linux.microsoft.com' HELO:'linux.microsoft.com' FROM:'jaskarankhurana@linux.microsoft.com' RCPT:'' X-RedHat-Spam-Score: -8.002 (ENV_AND_HDR_SPF_MATCH, SPF_HELO_PASS, SPF_PASS, USER_IN_DEF_SPF_WL) 13.77.154.182 linux.microsoft.com 13.77.154.182 linux.microsoft.com X-Scanned-By: MIMEDefang 2.84 on 10.5.110.41 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: dm-devel@redhat.com X-Mailman-Approved-At: Fri, 14 Jun 2019 04:15:49 -0400 Cc: scottsh@microsoft.com, snitzer@redhat.com, ebiggers@google.com, jmorris@namei.org, dm-devel@redhat.com, mpatocka@redhat.com, agk@redhat.com Subject: [dm-devel] [RFC PATCH v4 0/1] Add dm verity root hash pkcs7 sig validation. X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 14 Jun 2019 08:18:31 +0000 (UTC) X-Virus-Scanned: ClamAV using ClamSMTP This patch set adds in-kernel pkcs7 signature checking for the roothash of the dm-verity hash tree. The verification is to support cases where the roothash is not secured by Trusted Boot, UEFI Secureboot or similar technologies. One of the use cases for this is for dm-verity volumes mounted after boot, the root hash provided during the creation of the dm-verity volume has to be secure and thus in-kernel validation implemented here will be used before we trust the root hash and allow the block device to be created. Why we are doing validation in the Kernel? The reason is to still be secure in cases where the attacker is able to compromise the user mode application in which case the user mode validation could not have been trusted. The root hash signature validation in the kernel along with existing dm-verity implementation gives a higher level of confidence in the executable code or the protected data. Before allowing the creation of the device mapper block device the kernel code will check that the detached pkcs7 signature passed to it validates the roothash and the signature is trusted by builtin keys set at kernel creation. The kernel should be secured using Verified boot, UEFI Secure Boot or similar technologies so we can trust it. What about attacker mounting non dm-verity volumes to run executable code? This verification can be used to have a security architecture where a LSM can enforce this verification for all the volumes and by doing this it can ensure that all executable code runs from signed and trusted dm-verity volumes. Further patches will be posted that build on this and enforce this verification based on policy for all the volumes on the system. How are these changes tested? To generate and sign the roothash just dump the roothash returned by veritysetup format in a text file and then sign using the tool in the topic branch here: (fsverity uses the tool for signing, I just added a parameter there for testing) https://github.com/jaskarankhurana/fsverity-sign/tree/fs_verity_detached_pkcs7_for_dm_verity fsverity sign-dm-verity --key= --cert= veritysetup part of cryptsetup library was modified to take a optional root-hash-sig parameter. Commandline used to test the changes: veritysetup open --root-hash-sig= The changes for veritysetup are in a topic branch for now at: https://github.com/jaskarankhurana/veritysetup/tree/veritysetup_add_sig Changelog: v4: - Code review feedback given by Milan Broz. - Add documentation about the root hash signature parameter. - Bump up the dm-verity target version. - Provided way to sign and test with veritysetup in cover letter. v3: - Code review feedback given by Sasha Levin. - Removed EXPORT_SYMBOL_GPL since this was not required. - Removed "This file is released under the GPLv2" since we have SPDX identifier. - Inside verity_verify_root_hash changed EINVAL to ENOKEY when the key descriptor is not specified but due to force option being set it is expected. - Moved CONFIG check to inside verity_verify_get_sig_from_key. (Did not move the sig_opts_cleanup to inside verity_dtr as the sig_opts do not need to be allocated for the entire duration the block device is active unlike the verity structure, note verity_dtr is called only if verity_ctr fails or after the lifetime of the block device.) v2: - Code review feedback to pass the signature binary blob as a key that can be looked up in the kernel and be used to verify the roothash. [Suggested by Milan Broz] - Made the code related change suggested in review of v1. [Suggested by Balbir Singh] v1: - Add kconfigs to control dm-verity root has signature verification and use the signature if specified to verify the root hash. Jaskaran Khurana (1): Adds in-kernel pkcs7 sig checking the roothash of the dm-verity hash tree Documentation/device-mapper/verity.txt | 7 ++ drivers/md/Kconfig | 23 +++++ drivers/md/Makefile | 2 +- drivers/md/dm-verity-target.c | 36 ++++++- drivers/md/dm-verity-verify-sig.c | 132 +++++++++++++++++++++++++ drivers/md/dm-verity-verify-sig.h | 30 ++++++ 6 files changed, 224 insertions(+), 6 deletions(-) create mode 100644 drivers/md/dm-verity-verify-sig.c create mode 100644 drivers/md/dm-verity-verify-sig.h