linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: James Bottomley <jejb@linux.ibm.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Mimi Zohar <zohar@linux.ibm.com>,
	David Howells <dhowells@redhat.com>
Cc: kernel@pengutronix.de, "Jan Luebbe" <jlu@pengutronix.de>,
	"Ahmad Fatoum" <a.fatoum@pengutronix.de>,
	"James Morris" <jmorris@namei.org>,
	"Eric Biggers" <ebiggers@kernel.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	"Aymen Sghaier" <aymen.sghaier@nxp.com>,
	"Udit Agarwal" <udit.agarwal@nxp.com>,
	"Jan Luebbe" <j.luebbe@pengutronix.de>,
	"David Gstir" <david@sigma-star.at>,
	"Richard Weinberger" <richard@nod.at>,
	"Franck LENORMAND" <franck.lenormand@nxp.com>,
	"Sumit Garg" <sumit.garg@linaro.org>,
	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	[thread overview]
Message-ID: <342fe12286b5582b11e8c899bd9a63db2d4bf61c.1624365751.git-series.a.fatoum@pengutronix.de> (raw)
In-Reply-To: <cover.0e5d15050ce7cbc93b9b2f950cbd035bffc655fd.1624365751.git-series.a.fatoum@pengutronix.de>

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 <jlu@pengutronix.de>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
Manual resend.

To: James Bottomley <jejb@linux.ibm.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: Mimi Zohar <zohar@linux.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: "Horia Geantă" <horia.geanta@nxp.com>
Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
Cc: Udit Agarwal <udit.agarwal@nxp.com>
Cc: Jan Luebbe <j.luebbe@pengutronix.de>
Cc: David Gstir <david@sigma-star.at>
Cc: Richard Weinberger <richard@nod.at>
Cc: Franck LENORMAND <franck.lenormand@nxp.com>
Cc: Sumit Garg <sumit.garg@linaro.org>
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);
-- 
git-series 0.9.1

           reply	other threads:[~2021-06-22 12:45 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <cover.0e5d15050ce7cbc93b9b2f950cbd035bffc655fd.1624365751.git-series.a.fatoum@pengutronix.de>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=342fe12286b5582b11e8c899bd9a63db2d4bf61c.1624365751.git-series.a.fatoum@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=aymen.sghaier@nxp.com \
    --cc=david@sigma-star.at \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=franck.lenormand@nxp.com \
    --cc=horia.geanta@nxp.com \
    --cc=j.luebbe@pengutronix.de \
    --cc=jarkko@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=jlu@pengutronix.de \
    --cc=jmorris@namei.org \
    --cc=kernel@pengutronix.de \
    --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 \
    --cc=richard@nod.at \
    --cc=serge@hallyn.com \
    --cc=sumit.garg@linaro.org \
    --cc=udit.agarwal@nxp.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).