From: Mimi Zohar <zohar@linux.ibm.com>
To: Nikolaus Voss <nv@vosn.de>, David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, Yael Tzur <yaelt@google.com>
Subject: Re: [PATCH] KEYS: encrypted: fix key instantiation with user-provided data
Date: Tue, 20 Sep 2022 10:43:14 -0400 [thread overview]
Message-ID: <53730789a41358673b1715dd650706e9ffcb1199.camel@linux.ibm.com> (raw)
In-Reply-To: <20220919072317.E41421357@mail.steuer-voss.de>
On Fri, 2022-09-16 at 07:45 +0200, Nikolaus Voss wrote:
> Commit cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided
> decrypted data") added key instantiation with user provided decrypted data.
> The user data is hex-ascii-encoded but was just memcpy'ed to the binary buffer.
> Fix this to use hex2bin instead.
Thanks, Nikolaus. We iterated a number of times over what would be the
safest userspace input. One of the last changes was that the key data
should be hex-ascii-encoded. Unfortunately, the LTP
testcases/kernel/syscalls/keyctl09.c example isn't hex-ascii-encoded
and the example in Documentation/security/keys/trusted-encrypted.rst
just cat's a file. Both expect the length to be the length of the
userspace provided data. With this patch, when hex2bin() fails, there
is no explanation.
--
thanks,
Mimi
next prev parent reply other threads:[~2022-09-20 14:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 5:45 [PATCH] KEYS: encrypted: fix key instantiation with user-provided data Nikolaus Voss
2022-09-20 5:06 ` Jarkko Sakkinen
2022-09-20 7:58 ` Nikolaus Voss
2022-09-21 17:51 ` Jarkko Sakkinen
2022-09-28 13:03 ` Nikolaus Voss
2022-09-20 14:43 ` Mimi Zohar [this message]
2022-09-20 16:23 ` Nikolaus Voss
2022-09-20 22:53 ` Mimi Zohar
2022-09-21 7:24 ` Nikolaus Voss
2022-09-21 12:49 ` Mimi Zohar
2022-09-28 12:08 ` Nikolaus Voss
2022-09-28 16:33 ` Mimi Zohar
2022-10-05 10:04 ` Nikolaus Voss
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=53730789a41358673b1715dd650706e9ffcb1199.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=nv@vosn.de \
--cc=serge@hallyn.com \
--cc=yaelt@google.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 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.