Re: [PATCH] KEYS: encrypted: fix key instantiation with user-provided data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 20 Sep 2022, Mimi Zohar wrote:
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.

That's true. But it's true for all occurrences of hex2bin() in this file.
I could pr_err() an explanation, improve the trusted-encrypted.rst example and respin the patch. Should I, or do you have another suggestion?

I wasn't aware of keyctl09.c, but quickly looking into it, the user data _is_ hex-ascii-encoded, only the length is "wrong": Imho, the specified length should be the binary length as this is consistent with key-length specs in other cases (e.g. when loading the key from a blob). keyctl09.c could be easy to fix, if only the length is modified. Should I propose a patch? What is the correct/appropriate workflow there?

Thanks,
Niko



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux