From patchwork Tue Jun 22 12:45:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Ahmad Fatoum X-Patchwork-Id: 465304 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 146F8C48BDF for ; Tue, 22 Jun 2021 12:45:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EFF4E6135D for ; Tue, 22 Jun 2021 12:45:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231153AbhFVMsG (ORCPT ); Tue, 22 Jun 2021 08:48:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231717AbhFVMsG (ORCPT ); Tue, 22 Jun 2021 08:48:06 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B13D2C061574 for ; Tue, 22 Jun 2021 05:45:50 -0700 (PDT) Received: from dude.hi.pengutronix.de ([2001:67c:670:100:1d::7]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lvfma-0002yw-65; Tue, 22 Jun 2021 14:45:36 +0200 Received: from afa by dude.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1lvfmY-0000ic-Hs; Tue, 22 Jun 2021 14:45:34 +0200 From: Ahmad Fatoum To: James Bottomley , Jarkko Sakkinen , Mimi Zohar , David Howells Cc: kernel@pengutronix.de, Jan Luebbe , Ahmad Fatoum , James Morris , Eric Biggers , "Serge E. Hallyn" , =?utf-8?q?Horia_Geant?= =?utf-8?b?xIM=?= , Aymen Sghaier , Udit Agarwal , Jan Luebbe , David Gstir , Richard Weinberger , Franck LENORMAND , Sumit Garg , keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: [PATCH v2 2/6] KEYS: trusted: Allow import from existing key material for development Date: Tue, 22 Jun 2021 14:45:19 +0200 Message-Id: <342fe12286b5582b11e8c899bd9a63db2d4bf61c.1624365751.git-series.a.fatoum@pengutronix.de> X-Mailer: git-send-email 2.29.2 In-Reply-To: References: MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::7 X-SA-Exim-Mail-From: afa@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-crypto@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org A key aspect of trusted keys is that they are never disclosed to userspace in plain text. For development and debugging, it can be still useful to be able to supply a key in plain text from userspace. Implement an optional knob to support this according to the semantics Jan and Mimi had agreed on here[1]. [1] https://lore.kernel.org/linux-integrity/e8f149cddce55a4e4615396108e4c900cbec75a8.camel@pengutronix.de/ Suggested-by: Jan Luebbe Cc: Mimi Zohar Signed-off-by: Ahmad Fatoum --- Manual resend. To: James Bottomley To: Jarkko Sakkinen To: Mimi Zohar To: David Howells Cc: James Morris Cc: Eric Biggers Cc: "Serge E. Hallyn" Cc: "Horia Geantă" Cc: Aymen Sghaier Cc: Udit Agarwal Cc: Jan Luebbe Cc: David Gstir Cc: Richard Weinberger Cc: Franck LENORMAND Cc: Sumit Garg Cc: keyrings@vger.kernel.org Cc: linux-crypto@vger.kernel.org Cc: linux-integrity@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-security-module@vger.kernel.org --- Documentation/security/keys/trusted-encrypted.rst | 14 +++++++++++- security/keys/trusted-keys/Kconfig | 15 +++++++++++- security/keys/trusted-keys/trusted_core.c | 21 ++++++++++++++-- 3 files changed, 48 insertions(+), 2 deletions(-) diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst index 80d5a5af62a1..cc2e677b3bb6 100644 --- a/Documentation/security/keys/trusted-encrypted.rst +++ b/Documentation/security/keys/trusted-encrypted.rst @@ -188,6 +188,20 @@ Usage:: specific to TEE device implementation. The key length for new keys is always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). +Trusted Keys: import plain-text key for development +--------------------------------------------------- + +Usage:: + + keyctl add trusted name "import hex_key_material" ring + +For kernels built with ``CONFIG_TRUSTED_KEYS_DEVELOPMENT_IMPORT=y``, new +trusted keys can be created from existing key material supplied by userspace, +instead of using random numbers. Once defined, as with random trusted keys, +userspace cannot extract the plain-text key material again and will only +ever see encrypted blobs. This option should *not* be enabled for production +kernels. + Encrypted Keys usage -------------------- diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig index 24af4aaceebf..8bd69b252bf9 100644 --- a/security/keys/trusted-keys/Kconfig +++ b/security/keys/trusted-keys/Kconfig @@ -23,3 +23,18 @@ config TRUSTED_KEYS_TEE if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE comment "No trust source selected!" endif + +config TRUSTED_KEYS_DEVELOPMENT_IMPORT + bool "Allow creating TRUSTED KEYS from existing key material for development" + help + This option adds support for creating new trusted keys from + existing key material supplied by userspace, instead of using + random numbers. Once defined, as with random trusted keys, + userspace cannot extract the plain-text key material again + and will only ever see encrypted blobs. + + This option should *only* be enabled for debugging/development. + Also, consider using 'keyctl padd' instead of 'keyctl add' to + avoid exposing the plain-text key on the process command line. + + If you are unsure as to whether this is required, answer N. diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c index 8cab69e5d0da..2223e11c8bb5 100644 --- a/security/keys/trusted-keys/trusted_core.c +++ b/security/keys/trusted-keys/trusted_core.c @@ -46,12 +46,13 @@ static unsigned char migratable; enum { Opt_err, - Opt_new, Opt_load, Opt_update, + Opt_new, Opt_load, Opt_import, Opt_update, }; static const match_table_t key_tokens = { {Opt_new, "new"}, {Opt_load, "load"}, + {Opt_import, "import"}, {Opt_update, "update"}, {Opt_err, NULL} }; @@ -100,6 +101,21 @@ static int datablob_parse(char **datablob, struct trusted_key_payload *p) return -EINVAL; ret = Opt_load; break; + case Opt_import: + if (!IS_ENABLED(CONFIG_TRUSTED_KEYS_DEVELOPMENT_IMPORT)) + return -EINVAL; + /* first argument is unsealed blob */ + c = strsep(datablob, " \t"); + if (!c) + return -EINVAL; + p->key_len = strlen(c) / 2; + if (p->key_len < MIN_KEY_SIZE || p->key_len > MAX_KEY_SIZE) + return -EINVAL; + ret = hex2bin(p->key, c, p->key_len); + if (ret < 0) + return -EINVAL; + ret = Opt_import; + break; case Opt_update: ret = Opt_update; break; @@ -187,7 +203,8 @@ static int trusted_instantiate(struct key *key, ret = -EIO; goto out; } - + fallthrough; + case Opt_import: ret = static_call(trusted_key_seal)(payload, datablob); if (ret < 0) pr_info("key_seal failed (%d)\n", ret);