netdev - Re: [PATCH v2 2/3] net/handshake: Add support for PF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3E3F4884-A149-481C-9D5D-663498F34D74@redhat.com>
Date:   Tue, 31 Jan 2023 15:26:36 -0500
From:   Benjamin Coddington <bcodding@...hat.com>
To:     Chuck Lever III <chuck.lever@...cle.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev <netdev@...r.kernel.org>,
        hare@...e.com, David Howells <dhowells@...hat.com>,
        Olga Kornievskaia <kolga@...app.com>, jmeneghi@...hat.com,
        Jeff Layton <jlayton@...hat.com>
Subject: Re: [PATCH v2 2/3] net/handshake: Add support for PF_HANDSHAKE

On 31 Jan 2023, at 14:34, Chuck Lever III wrote:

>> On Jan 31, 2023, at 2:30 PM, Jakub Kicinski <kuba@...nel.org> wrote:
>>
>>> On Tue, 31 Jan 2023 15:18:02 +0000 Chuck Lever III wrote:
>>> And, do you have a preferred mechanism or code sample for
>>> installing a socket descriptor?
>>
>> I must admit - I don't.
>
> As part of responding to the handshake daemon's netlink call,
> I'm thinking of doing something like:
>
> get_unused_fd_flags(), then sock_alloc_file(), and then fd_install()

It seems odd to me that we're not taking advantage of request_key() to do
this work.  It was designed for exactly this problem: the kernel needs
something/work (a tls handhsake) from/done in userspace.

I have a working implementation here:
https://github.com/bcodding/linux/tree/tls_keys

Perhaps there's no interest because no one likes call_usermode_helper(),
which cannot figure out what set of namespace(s) to use, but there's a
solution for that as well: keyagents can represent a running process to
satisfy request_key().
https://lore.kernel.org/linux-nfs/cover.1657624639.git.bcodding@redhat.com/

Keyagents are not required to simply pass socket fds to userspace, however
they do create a flexible way for containers to specify exactly where the
kernel should send various key requests.

I am happy to continue to explain how these approaches work, though I would
also much prefer to see us doing handshakes in-kernel.

Ben