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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ