All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 2/6] KEYS: trusted: Allow import from existing key material for development
       [not found] <cover.0e5d15050ce7cbc93b9b2f950cbd035bffc655fd.1624365751.git-series.a.fatoum@pengutronix.de>
@ 2021-06-22 12:45 ` Ahmad Fatoum
  0 siblings, 0 replies; only message in thread
From: Ahmad Fatoum @ 2021-06-22 12:45 UTC (permalink / raw)
  To: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells
  Cc: kernel, Jan Luebbe, Ahmad Fatoum, James Morris, Eric Biggers,
	Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Udit Agarwal, Jan Luebbe, David Gstir,
	Richard Weinberger, Franck LENORMAND, Sumit Garg, keyrings,
	linux-crypto, linux-integrity, linux-kernel,
	linux-security-module

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

^ permalink raw reply related	[flat|nested] only message in thread

only message in thread, other threads:[~2021-06-22 12:45 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <cover.0e5d15050ce7cbc93b9b2f950cbd035bffc655fd.1624365751.git-series.a.fatoum@pengutronix.de>
2021-06-22 12:45 ` [PATCH v2 2/6] KEYS: trusted: Allow import from existing key material for development Ahmad Fatoum

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.