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: <0DA01246-69CE-4509-9397-594ACC038852@oracle.com>
Date:   Sun, 29 Jan 2023 16:53:17 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Stephen Hemminger <stephen@...workplumber.org>,
        Jakub Kicinski <kuba@...nel.org>
CC:     netdev <netdev@...r.kernel.org>, "hare@...e.com" <hare@...e.com>,
        David Howells <dhowells@...hat.com>,
        Olga Kornievskaia <kolga@...app.com>,
        "jmeneghi@...hat.com" <jmeneghi@...hat.com>,
        Benjamin Coddington <bcodding@...hat.com>,
        Jeff Layton <jlayton@...hat.com>
Subject: Re: [PATCH v2 2/3] net/handshake: Add support for PF_HANDSHAKE

> On Jan 28, 2023, at 12:40 PM, Stephen Hemminger <stephen@...workplumber.org> wrote:
> 
> On Sat, 28 Jan 2023 00:32:12 -0800
> Jakub Kicinski <kuba@...nel.org> wrote:
> 
>> On Thu, 26 Jan 2023 11:02:22 -0500 Chuck Lever wrote:
>>> I've designed a way to pass a connected kernel socket endpoint to
>>> user space using the traditional listen/accept mechanism. accept(2)
>>> gives us a well-worn building block that can materialize a connected
>>> socket endpoint as a file descriptor in a specific user space
>>> process. Like any open socket descriptor, the accepted FD can then
>>> be passed to a library such as GnuTLS to perform a TLS handshake.  
>> 
>> I can't bring myself to like the new socket family layer.
>> I'd like a second opinion on that, if anyone within netdev
>> is willing to share..
> 
> Why not just pass fd's with Unix Domain socket?

Or a pipe. We do need a queue for handshake requests, and a
pipe provides a reliable mechanism to ensure that handshake
requests are not dropped.

The question I have is: would the application then just start
using that fd number as if it had been opened or accepted? Is
reading the fd from the pipe actually an implicit accept(2)?

> The application is going to need to be changed to handle new AF already.

The only application that has to deal with PF_HANDSHAKE is the
user space daemon that performs the handshakes, an example of
which we provide here:

  https://github.com/oracle/ktls-utils

This is for handling handshakes on behalf of kernel TLS consumers.
The new family would not be used by any existing application in
user space.

> Also, expanding the address families has security impacts as well.
> Either all the container and LSM's need to deny your new AF or they need
> to be taught to validate whether this a valid operation.

It wasn't clear to me yesterday whether Jakub's objection was to
the listen/poll/accept part of this contraption, or whether he
was uncomfortable specifically with the addition of PF_HANDSHAKE.
I can certainly see that a new socket family is unwieldy from a
security perspective.

However, what if listen/poll/accept was used with an existing
address family, maybe AF_INET, with either a special bind address,
with a socket option set, or perhaps a new netlink operation can
inform the kernel that the listener is specifically for transport
layer handshake requests...?

A socket that comes from an accept(2) on a PF_HANDSHAKE listener
is also a PF_HANDSHAKE socket, though it behaves in every other
aspect like an AF_INET/AF_INET6 socket. So, using an AF_INET/6
listener instead might be nicer overall.

--
Chuck Lever