Re: [PATCH 2/4] tls-handshake: add 'keyring' netlink attribute

[Chuck Lever III <chuck.lever@oracle.com>]

> On Feb 17, 2023, at 7:24 AM, Hannes Reinecke <hare@suse.de> wrote:
> 
> On 2/17/23 13:00, Chuck Lever III wrote:
>>> On Feb 17, 2023, at 6:31 AM, Hannes Reinecke <hare@suse.de> wrote:
>>> 
>>> Add a 'keyring' netlink attribute to the 'request' netlink
>>> message to allow the kernel to communicate the keyring to use
>>> to userspace.
>> Can you add some detail about the use case? I'm not
>> clear about how the keyring is to be used.
>> Is this keyring going to be the same for all operations
>> with this particular tlshd? If that's the case, why not
>> have tlshd do a GET_KEYRING downcall once when it starts
>> up?
> And that's the key (sic!) here:
> with this attribute each tlshd instance can have a _different_
> keyring.

What do you mean by "tlshd instance"? Do you mean each tlshd
child process needs its own keyring?


> Idea is to prep the server side with the keyring to use, and then
> reflect that choice to the userspace application such that it can
> lookup the key in that keyring, too.
> 
> (Note to self: need to change the initial keyring to be the process keyring, not the session keyring for that to work)
> 
> With that we can be sure that both sides (kernel and userspace) will have access to the same set of keys.
> Idea is to have only _one_ place which need to be configured; in this
> case you would need to update the kernel side to allow for individual
> keyrings.
> Without this you would need to configure tlshd to use the correct keys, and it'll be rather tricky to configure different keys for individual connections.

I thought the issue was keeping the keys private by setting up
a keyring that is accessible only to the kernel and that tlshd
instance? Did I miss something?

Seems like the tlshd child's process keyring is already set up
this way? I'd like to understand if there's already something
available to fill this role.

--
Chuck Lever