netdev - Re: [PATCH bpf-next] xsk: honor SO

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]

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!