From: Chuck Lever III <chuck.lever@oracle.com>
To: Hannes Reinecke <hare@suse.de>
Cc: "kernel-tls-handshake@lists.linux.dev"
<kernel-tls-handshake@lists.linux.dev>
Subject: Re: [PATCH 2/4] tls-handshake: add 'keyring' netlink attribute
Date: Fri, 17 Feb 2023 12:56:49 +0000 [thread overview]
Message-ID: <1CEEDD45-B394-44C8-B755-DDBE71965BCF@oracle.com> (raw)
In-Reply-To: <dd737d0d-0bef-db60-b49b-b21b75812bea@suse.de>
> On Feb 17, 2023, at 7:48 AM, Hannes Reinecke <hare@suse.de> wrote:
>
> On 2/17/23 13:32, Chuck Lever III wrote:
>>> 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?
> It doesn't 'need' it. It already has (well, actually there are three keyring, one session-wide, one process-wide, and one per thread)
> And all this 'keyring' attribute does (or should be doing) is allowing userspace to link that keyring into the process 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?
> No, that's precisely it.
> By having a keyring attribute we allow for configuration of a keyring per connection.
>
>> 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.
> The issue is to make the keys _available_ to that keyring.
> As it stands, tlshd is using fork() for each handshake.
> So we have one master process, and one process per handshake.
> The session keyring will be identical for the of these instances.
> The process keyring will be different for each of these.
> And the per-handshake process needs to be able to lookup keys; these keys either must be in one of the default keyrings, linked to one of the default keyrings, or have correct permissions.
> The last case we've dismissed as we want to restrict the permissions.
> The first case (per-session keyrings) is essentially the config option
> (which necessarily is identical for all handshake processed).
> And this patch now covers the second option, of having _different_ keyrings for each handshake process.
>
> Idea is that you configure the in-kernel callers of the handshake to provide the correct keyring.
I'm warming to the idea of having a private keyring per handshake.
Thanks for explaining.
> EG for nvme-tcp plan is to pass the keyring with the 'nvme connect' call, and configure the keyring via the 'configfs' interface for the server side.
> If different keyrings should be used. If not stick with the default '.tls' keyring.
> For which, incidentally, I've got another patch, which I probably should send out, too.
>
> Cheers,
>
> Hannes
--
Chuck Lever
next prev parent reply other threads:[~2023-02-17 12:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 11:31 [PATCH 0/4] tls-handshake: server-side support Hannes Reinecke
2023-02-17 11:31 ` [PATCH 1/4] tls-handshake: add 'timeout' netlink attribute Hannes Reinecke
2023-02-17 11:58 ` Chuck Lever III
2023-02-17 12:17 ` Hannes Reinecke
2023-02-17 12:26 ` Chuck Lever III
2023-02-17 12:36 ` Hannes Reinecke
2023-02-17 12:38 ` Chuck Lever III
2023-02-17 11:31 ` [PATCH 2/4] tls-handshake: add 'keyring' " Hannes Reinecke
2023-02-17 12:00 ` Chuck Lever III
2023-02-17 12:24 ` Hannes Reinecke
2023-02-17 12:32 ` Chuck Lever III
2023-02-17 12:48 ` Hannes Reinecke
2023-02-17 12:56 ` Chuck Lever III [this message]
2023-02-17 11:31 ` [PATCH 3/4] net/tls_handshake: split tls_server_hello() Hannes Reinecke
2023-02-17 11:31 ` [PATCH 4/4] tls_handshake: add 'keyring' argument to server hello Hannes Reinecke
2023-02-17 11:56 ` [PATCH 0/4] tls-handshake: server-side support Chuck Lever III
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=1CEEDD45-B394-44C8-B755-DDBE71965BCF@oracle.com \
--to=chuck.lever@oracle.com \
--cc=hare@suse.de \
--cc=kernel-tls-handshake@lists.linux.dev \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).