[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53730789a41358673b1715dd650706e9ffcb1199.camel@linux.ibm.com>
Date: Tue, 20 Sep 2022 10:43:14 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Nikolaus Voss <nv@...n.de>, David Howells <dhowells@...hat.com>,
Jarkko Sakkinen <jarkko@...nel.org>,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>
Cc: linux-integrity@...r.kernel.org, keyrings@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, Yael Tzur <yaelt@...gle.com>
Subject: Re: [PATCH] KEYS: encrypted: fix key instantiation with
user-provided data
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
Powered by blists - more mailing lists