[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <94b00e51-aaac-5e7c-d447-f45af408e389@iogearbox.net>
Date: Tue, 4 Jul 2023 11:16:09 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Jason Wang <jasowang@...hat.com>,
Ilya Maximets <i.maximets@....org>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org,
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, Stefan Hajnoczi <stefanha@...hat.com>
Subject: Re: [PATCH bpf-next] xsk: honor SO_BINDTODEVICE on bind
On 7/4/23 4:31 AM, Jason Wang wrote:
> On Tue, Jul 4, 2023 at 1:53 AM Ilya Maximets <i.maximets@....org> 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>
>
> Acked-by: Jason Wang <jasowang@...hat.com>
>
> Is this a stable material or not?
To me this is a bug rather than 'feature', so I applied it to bpf tree and
also added Fixes tag. Thanks everyone!
Powered by blists - more mailing lists