[<prev] [next>] [day] [month] [year] [list]
Message-Id: <342fe12286b5582b11e8c899bd9a63db2d4bf61c.1624365751.git-series.a.fatoum@pengutronix.de>
Date: Tue, 22 Jun 2021 14:45:19 +0200
From: Ahmad Fatoum <a.fatoum@...gutronix.de>
To: James Bottomley <jejb@...ux.ibm.com>,
Jarkko Sakkinen <jarkko@...nel.org>,
Mimi Zohar <zohar@...ux.ibm.com>,
David Howells <dhowells@...hat.com>
Cc: kernel@...gutronix.de, Jan Luebbe <jlu@...gutronix.de>,
Ahmad Fatoum <a.fatoum@...gutronix.de>,
James Morris <jmorris@...ei.org>,
Eric Biggers <ebiggers@...nel.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Horia Geantă <horia.geanta@....com>,
Aymen Sghaier <aymen.sghaier@....com>,
Udit Agarwal <udit.agarwal@....com>,
Jan Luebbe <j.luebbe@...gutronix.de>,
David Gstir <david@...ma-star.at>,
Richard Weinberger <richard@....at>,
Franck LENORMAND <franck.lenormand@....com>,
Sumit Garg <sumit.garg@...aro.org>, keyrings@...r.kernel.org,
linux-crypto@...r.kernel.org, linux-integrity@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: [PATCH v2 2/6] KEYS: trusted: Allow import from existing key material for development
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@...gutronix.de>
Cc: Mimi Zohar <zohar@...ux.ibm.com>
Signed-off-by: Ahmad Fatoum <a.fatoum@...gutronix.de>
---
Manual resend.
To: James Bottomley <jejb@...ux.ibm.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
To: Mimi Zohar <zohar@...ux.ibm.com>
To: David Howells <dhowells@...hat.com>
Cc: James Morris <jmorris@...ei.org>
Cc: Eric Biggers <ebiggers@...nel.org>
Cc: "Serge E. Hallyn" <serge@...lyn.com>
Cc: "Horia Geantă" <horia.geanta@....com>
Cc: Aymen Sghaier <aymen.sghaier@....com>
Cc: Udit Agarwal <udit.agarwal@....com>
Cc: Jan Luebbe <j.luebbe@...gutronix.de>
Cc: David Gstir <david@...ma-star.at>
Cc: Richard Weinberger <richard@....at>
Cc: Franck LENORMAND <franck.lenormand@....com>
Cc: Sumit Garg <sumit.garg@...aro.org>
Cc: keyrings@...r.kernel.org
Cc: linux-crypto@...r.kernel.org
Cc: linux-integrity@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Cc: linux-security-module@...r.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
Powered by blists - more mailing lists