linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: David Howells <dhowells@redhat.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	dm-devel@redhat.com, Song Liu <song@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	Jonathan Corbet <corbet@lwn.net>
Cc: kernel@pengutronix.de, Ahmad Fatoum <a.fatoum@pengutronix.de>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-raid@vger.kernel.org, keyrings@vger.kernel.org,
	linux-mtd@lists.infradead.org,
	linux-security-module@vger.kernel.org,
	linux-integrity@vger.kernel.org
Subject: [RFC PATCH v1 4/4] ubifs: auth: consult encrypted and trusted keys if no logon key was found
Date: Thu, 22 Jul 2021 11:18:02 +0200	[thread overview]
Message-ID: <f5891611f329583baef32089c8b322850d81166a.1626945419.git-series.a.fatoum@pengutronix.de> (raw)
In-Reply-To: <cover.b2fdd70b830d12853b12a12e32ceb0c8162c1346.1626945419.git-series.a.fatoum@pengutronix.de>

Currently, UBIFS auth_key can only be a logon key: This is a user key
that's provided to the kernel in plaintext and that then remains within
the kernel. Linux also supports trusted and encrypted keys, which have
stronger guarantees: They are only exposed to userspace in encrypted
form and, in the case of trusted keys, can be directly rooted to a trust
source like a TPM chip.

Add support for auth_key to be either a logon, encrypted or trusted key.
At mount time, the keyring will be searched for a key with the supplied
name in that order.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
 Documentation/filesystems/ubifs.rst |  2 +-
 fs/ubifs/auth.c                     | 19 ++++++++++++-------
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/Documentation/filesystems/ubifs.rst b/Documentation/filesystems/ubifs.rst
index e6ee99762534..12d08458b3d7 100644
--- a/Documentation/filesystems/ubifs.rst
+++ b/Documentation/filesystems/ubifs.rst
@@ -101,7 +101,7 @@ compr=zlib              override default compressor and set it to "zlib"
 auth_key=		specify the key used for authenticating the filesystem.
 			Passing this option makes authentication mandatory.
 			The passed key must be present in the kernel keyring
-			and must be of type 'logon'
+			and must be of type 'logon', 'encrypted' or 'trusted'.
 auth_hash_name=		The hash algorithm used for authentication. Used for
 			both hashing and for creating HMACs. Typical values
 			include "sha256" or "sha512"
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index 6a0b8d858d81..af8e9eb58a60 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -14,6 +14,8 @@
 #include <crypto/hash.h>
 #include <crypto/algapi.h>
 #include <keys/user-type.h>
+#include <keys/trusted-type.h>
+#include <keys/encrypted-type.h>
 #include <keys/asymmetric-type.h>
 
 #include "ubifs.h"
@@ -256,9 +258,10 @@ out_destroy:
 int ubifs_init_authentication(struct ubifs_info *c)
 {
 	struct key *keyring_key;
-	const struct user_key_payload *ukp;
 	int err;
+	unsigned int len;
 	char hmac_name[CRYPTO_MAX_ALG_NAME];
+	const void *key_material;
 
 	if (!c->auth_hash_name) {
 		ubifs_err(c, "authentication hash name needed with authentication");
@@ -277,6 +280,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
 		 c->auth_hash_name);
 
 	keyring_key = request_key(&key_type_logon, c->auth_key_name, NULL);
+	if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_ENCRYPTED_KEYS))
+		keyring_key = request_key(&key_type_encrypted, c->auth_key_name, NULL);
+	if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_TRUSTED_KEYS))
+		keyring_key = request_key(&key_type_trusted, c->auth_key_name, NULL);
 
 	if (IS_ERR(keyring_key)) {
 		ubifs_err(c, "Failed to request key: %ld",
@@ -286,12 +293,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
 
 	down_read(&keyring_key->sem);
 
-	ukp = user_key_payload_locked(keyring_key);
-	if (!ukp) {
-		/* key was revoked before we acquired its semaphore */
-		err = -EKEYREVOKED;
+	key_material = key_extract_material(keyring_key, &len);
+	err = PTR_ERR_OR_ZERO(key_material);
+	if (err < 0)
 		goto out;
-	}
 
 	c->hash_tfm = crypto_alloc_shash(c->auth_hash_name, 0, 0);
 	if (IS_ERR(c->hash_tfm)) {
@@ -324,7 +329,7 @@ int ubifs_init_authentication(struct ubifs_info *c)
 		goto out_free_hmac;
 	}
 
-	err = crypto_shash_setkey(c->hmac_tfm, ukp->data, ukp->datalen);
+	err = crypto_shash_setkey(c->hmac_tfm, key_material, len);
 	if (err)
 		goto out_free_hmac;
 
-- 
git-series 0.9.1

  parent reply	other threads:[~2021-07-22  9:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-22  9:17 [RFC PATCH v1 0/4] keys: introduce key_extract_material helper Ahmad Fatoum
2021-07-22  9:17 ` [RFC PATCH v1 1/4] " Ahmad Fatoum
2021-07-22  9:18 ` [RFC PATCH v1 2/4] dm: crypt: use new " Ahmad Fatoum
2021-07-22  9:18 ` [RFC PATCH v1 3/4] ubifs: auth: remove never hit key type error check Ahmad Fatoum
2021-07-22  9:18 ` Ahmad Fatoum [this message]
2021-08-06 10:53 ` [RFC PATCH v1 0/4] keys: introduce key_extract_material helper Ahmad Fatoum

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=f5891611f329583baef32089c8b322850d81166a.1626945419.git-series.a.fatoum@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=agk@redhat.com \
    --cc=corbet@lwn.net \
    --cc=dhowells@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=jarkko@kernel.org \
    --cc=jmorris@namei.org \
    --cc=kernel@pengutronix.de \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=richard@nod.at \
    --cc=serge@hallyn.com \
    --cc=snitzer@redhat.com \
    --cc=song@kernel.org \
    /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).