linux-kernel - Re: [PATCH v4 5/7] net/tcp: Don't add key with non-matching VRF on connected sockets

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: <CANn89iLLsTUu1k0pBDYNX8LX0z+JGr12OaC-zu94WcR8WbErUA@mail.gmail.com>
Date:   Wed, 29 Nov 2023 18:59:20 +0100
From:   Eric Dumazet <edumazet@...gle.com>
To:     Dmitry Safonov <dima@...sta.com>
Cc:     David Ahern <dsahern@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        linux-kernel@...r.kernel.org,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Francesco Ruggeri <fruggeri05@...il.com>,
        Salam Noureddine <noureddine@...sta.com>,
        Simon Horman <horms@...nel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH v4 5/7] net/tcp: Don't add key with non-matching VRF on
 connected sockets

On Wed, Nov 29, 2023 at 5:57 PM Dmitry Safonov <dima@...sta.com> wrote:
>
> If the connection was established, don't allow adding TCP-AO keys that
> don't match the peer. Currently, there are checks for ip-address
> matching, but L3 index check is missing. Add it to restrict userspace
> shooting itself somewhere.
>
> Yet, nothing restricts the CAP_NET_RAW user from trying to shoot
> themselves by performing setsockopt(SO_BINDTODEVICE) or
> setsockopt(SO_BINDTOIFINDEX) over an established TCP-AO connection.
> So, this is just "minimum effort" to potentially save someone's
> debugging time, rather than a full restriction on doing weird things.
>
> Fixes: 248411b8cb89 ("net/tcp: Wire up l3index to TCP-AO")
> Signed-off-by: Dmitry Safonov <dima@...sta.com>

Reviewed-by: Eric Dumazet <edumazet@...gle.com>