netdev - Re: [PATCH net-next] fou: Support binding FoU socket

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] [day] [month] [year] [list]

Message-ID: <CAKfDRXiEJ3M-JcUi8u=dJNk=55FL+OfC05yEbyK881byWdND6g@mail.gmail.com>
Date:   Sun, 24 Mar 2019 22:38:48 +0100
From:   Kristian Evensen <kristian.evensen@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] fou: Support binding FoU socket

Hi,

On Thu, Mar 21, 2019 at 9:10 PM David Miller <davem@...emloft.net> wrote:
> This seems to allow adding both a wildcarded and a non-wildcarded fou
> socket, which otherwise has overlapping match scenerios.
>
> I don't think you want to allow that unless you can determine that
> you aren't creating a situation where multiple fou sockets could
> match the same tunneled packet.

(Apologies to David for multiple copies of this reply. I thought I was
safe from HTML-encoded emails when using Gmail through the browser.
Turns out not to be true for mobile ...)

Thanks for your comments and apoligies for my late reply, Gmail
flagged you message as spam for some reason.

I tried to test and make sure that we would not get any false
positives when mixing non-wildcarded/wildcarded sockets. In my tests,
I first created a wildcard socket bound to port 9999. I then tried to
add a second, non-wildcarded socket bound to the same port. I also
tried to fetch and delete the socket, including souce address, peer
address or interface index in the netlink request. Both the create,
fetch and delete request failed. Deleting/fetching the socket was only
successful when my netlink request attributes matched those used to
create the socket.

I then did the same tests, but with a socket bound to a local ip
address, a socket bound to a local address + interface, and a bound
socket that was also «connected» to a peer. Add only worked when no
socket with the matching source address/interface (or wildcard)
existed, while fetch/delete was only succesful when all attributes
matched.

Perhaps there is something I am misunderstanding, or a case I am not aware of?

Thanks again for your comments!

BR,
Kristian