netdev - Re: [RFC] Socket termination for policy enforcement and load-balancing

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: <CABG=zsCTiqt4QuPo70xiGePh1F4ntyNh4-bsVh_DKvSw=CkWjA@mail.gmail.com>
Date:   Sun, 4 Sep 2022 10:41:16 -0700
From:   Aditi Ghag <aditivghag@...il.com>
To:     sdf@...gle.com
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [RFC] Socket termination for policy enforcement and load-balancing

On Wed, Aug 31, 2022 at 3:02 PM <sdf@...gle.com> wrote:
>
> On 08/31, Aditi Ghag wrote:
> [...]
>
> > - The sock_destroy API added for similar Android use cases is
> > effective in tearing down sockets. The API is behind the
> > CONFIG_INET_DIAG_DESTROY config that's disabled by default, and
> > currently exposed via SOCK_DIAG netlink infrastructure in userspace.
> > The sock destroy handlers for TCP and UDP protocols send ECONNABORTED
> > error code to sockets related to the abort state as mentioned in RFC
> > 793.
>
> > - Add unreachable routes for deleted backends. I experimented with
> > this approach with my colleague, Nikolay Aleksandrov. We found that
> > TCP and connected UDP sockets in the established state simply ignore
> > the ICMP error messages, and continue to send data in the presence of
> > such routes. My read is that applications are ignoring the ICMP errors
> > reported on sockets [2].
>
> [..]
>
> > - Use BPF (sockets) iterator to identify sockets connected to a
> > deleted backend. The BPF (sockets) iterator is network namespace aware
> > so we'll either need to enter every possible container network
> > namespace to identify the affected connections, or adapt the iterator
> > to be without netns checks [3]. This was discussed with my colleague
> > Daniel Borkmann based on the feedback he shared from the LSFMMBPF
> > conference discussions.
>
> Maybe something worth fixing as well even if you end up using netlink?
> Having to manually go over all networking namespaces (if I want
> to iterate over all sockets on the host) doesn't seem feasible?

SOCK_DIAG netlink infrastructure also has similar netns checks. The
iterator approach
would allow us to invoke sock destroy handlers from BPF though.

>
> [...]
>
> > [1] https://github.com/cilium/cilium
> > [2] https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_ipv4.c#L464
> > [3] https://github.com/torvalds/linux/blob/master/net/ipv4/udp.c#L3011
> > [4]
> > https://github.com/torvalds/linux/blob/master/net/core/sock_diag.c#L298