[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <64a33b4fcccc_6520520825@john.notmuch>
Date: Mon, 03 Jul 2023 14:19:11 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Ilya Maximets <i.maximets@....org>,
netdev@...r.kernel.org,
bpf@...r.kernel.org
Cc: Björn Töpel <bjorn@...nel.org>,
Magnus Karlsson <magnus.karlsson@...el.com>,
Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
Jason Wang <jasowang@...hat.com>,
Stefan Hajnoczi <stefanha@...hat.com>,
Ilya Maximets <i.maximets@....org>
Subject: RE: [PATCH bpf-next] xsk: honor SO_BINDTODEVICE on bind
Ilya Maximets wrote:
> Initial creation of an AF_XDP socket requires CAP_NET_RAW capability.
> A privileged process might create the socket and pass it to a
> non-privileged process for later use. However, that process will be
> able to bind the socket to any network interface. Even though it will
> not be able to receive any traffic without modification of the BPF map,
> the situation is not ideal.
>
> Sockets already have a mechanism that can be used to restrict what
> interface they can be attached to. That is SO_BINDTODEVICE.
>
> To change the SO_BINDTODEVICE binding the process will need CAP_NET_RAW.
>
> Make xsk_bind() honor the SO_BINDTODEVICE in order to allow safer
> workflow when non-privileged process is using AF_XDP.
>
> The intended workflow is following:
>
> 1. First process creates a bare socket with socket(AF_XDP, ...).
> 2. First process loads the XSK program to the interface.
> 3. First process adds the socket fd to a BPF map.
> 4. First process ties socket fd to a particular interface using
> SO_BINDTODEVICE.
> 5. First process sends socket fd to a second process.
> 6. Second process allocates UMEM.
> 7. Second process binds socket to the interface with bind(...).
> 8. Second process sends/receives the traffic.
>
> All the steps above are possible today if the first process is
> privileged and the second one has sufficient RLIMIT_MEMLOCK and no
> capabilities. However, the second process will be able to bind the
> socket to any interface it wants on step 7 and send traffic from it.
> With the proposed change, the second process will be able to bind
> the socket only to a specific interface chosen by the first process
> at step 4.
>
> Acked-by: Magnus Karlsson <magnus.karlsson@...el.com>
> Signed-off-by: Ilya Maximets <i.maximets@....org>
> ---
LGTM.
Acked-by: John Fastabend <john.fastabend@...il.com>
Powered by blists - more mailing lists