From: Hannes Reinecke <hare@suse.de>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: "kernel-tls-handshake@lists.linux.dev"
<kernel-tls-handshake@lists.linux.dev>
Subject: Re: new netlink attributes - thoughts
Date: Mon, 27 Feb 2023 16:01:17 +0100 [thread overview]
Message-ID: <9e5fbf9a-f3e9-6067-821d-b343c3170851@suse.de> (raw)
In-Reply-To: <4B4C7760-3634-44FD-BEDD-23A21C421AB7@oracle.com>
On 2/27/23 15:44, Chuck Lever III wrote:
>
>
>> On Feb 27, 2023, at 2:35 AM, Hannes Reinecke <hare@suse.de> wrote:
>>
>> On 2/21/23 23:32, Chuck Lever III wrote:
>>> Thanks for the broad conversation during this morning's call.
>>> We're now using netlink to handle the interactions between the kernel
>>> and handshake agents (eg, tlshd), replacing the old listen/poll/
>>> accept/close mechanism.
>>> Before asking netdev to merge the handshake upcall mechanism, I'd like
>>> the netlink protocol to be stable. The protocol is extensible, but
>>> because it comprises an API contract between the kernel and user space,
>>> we should strive to minimize any significant changes once it has been
>>> merged into the kernel.
>>> For those who are not familiar with netlink:
>>> - A netlink operation is simply a remote procedure call.
>>> - An attribute is simply an argument or result data item within a
>>> netlink operation.
>>> Aside from the attributes that contain the socket file descriptor and
>>> the status of the session, there are three more recent additions that
>>> we need to close on.
>>> 1. remote-peerid
>>> The DONE netlink operation now carries the key serial number of a key
>>> that contains the remote peer's identity. The content of that key can
>>> be an x.509 certificate or another form of peer identity.
>>> I'd like to make this into an attribute that can appear more than once
>>> in the DONE reply, since more than one identity can be passed during a
>>> handshake negotiation.
>>> This information would then be passed back to the kernel consumer who
>>> requested the handshake so that it can make security policy decisions
>>> based on the remote's identity.
>> I'm all for the attribute method; we should keep the number of static (ie non-attribute) content as small as possible to allow for easier protocol updates in future versions.
>>
>> The multi-identity issue seems to be less pressing, as every implementation I've looked at only supports a single identity.
>>
>> But having only a single identity means that we need to distinguish (at least) three status cases in the DONE call:
>> - OK
>> - Identity rejected
>> - Failure
>> As the caller might wish to retry with another identification.
>
> The DONE call now returns an errno status. We can define as many
> particular failure modes as we like.
>
Sure. But we need to specify which error type is returned under which
circumstance.
Also cf my comments to the patchset; might be an idea to return the
positive errno number, not the negative one (seeing that the attribute
is u32 ...)
>
>>> 3. keyring
>>> The idea is to have a private keyring that the handshake agent and the
>>> user requesting the session would use to share certificates, PSKs, and
>>> bundles.
>>> Hannes suggested passing that keyring's serial to the handshake agent,
>>> to have it link that keyring into its own session keyring.
>>> It might be a bit more secure if the kernel links that keyring into the
>>> handshake agent's session keyring as part of the ACCEPT operation.
>> Good point.
>> Question, though:
>> Session, thread, or process keyring?
>> I would opt for the process keyring, as that would match the internal
>> design of tlshd and would (in theory) allow to have different keyrings for each ACCEPT
>>
>>> We might also specify the name of a keyring containing other additional
>>> shared items, via /etc/tlshd.conf. That's outside the realm of netlink
>>> attributes, though.
>> Not quite. We could keep the 'keyring' attribute for the netlink interface, and allow
>> it to be specified by the REQUEST call.
>> The kernel part would then link/use that keyring for their internal lookup.
>
> If tlshd links in any keyrings that might be mentioned in /etc/tlshd.conf,
> I'm not sure the kernel needs to take any action?
>
True.
We could clarify that the kernel should always use the process keyring
to lookup keys, thereby requiring that any other keyrings will need to
be linked into the process keyring prior to lookup.
>
>> Another issue when dealing with keyrings and keys in general:
>> Should we aim for specific types, or should we stay with the generic 'user' type?
>
> I played with using an asymmetric key type for the x509 certificates. The
> problem is that the kernel's asymmetric key support wants to parse the
> key into a data structure; it doesn't actually save the certificate itself.
>
> We need to preserve the certificate because that is then handed back to
> user space to do the handshake. So we are forced to use a key type that
> does not adulterate its content.
>
Thought so. But as that's the case: shouldn't we add an attribute for
the keytype, too?
Cheers,
Hannes
prev parent reply other threads:[~2023-02-27 15:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-21 22:32 new netlink attributes - thoughts Chuck Lever III
2023-02-27 7:35 ` Hannes Reinecke
2023-02-27 14:44 ` Chuck Lever III
2023-02-27 15:01 ` Hannes Reinecke [this message]
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=9e5fbf9a-f3e9-6067-821d-b343c3170851@suse.de \
--to=hare@suse.de \
--cc=chuck.lever@oracle.com \
--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).