Bug 2229902

(In reply to lagoho7 from comment #0)
> Created attachment 1982239 [details]
> ifconfig output, tcpdump output and kernel logs
> 
> 1. Please describe the problem:
> 
>    It is possible for data that was sent through a socket bound to an IP
> address
>    using bind(2) to escape to another interface.

This sentence doesn't really make sense. In the context of IP sockets, bind(2)
works on IP addresses, not on network interfaces. It has no reason to put any
restriction on the output device.

>    To demonstrate the problem, you need one interface with Internet access
> and
>    another interface with no Internet access. You should bind a socket to the
>    interface with no Internet access, then try to send data through that
> socket
>    to a destination on the Internet. You will find that the data gets sent
>    successfully.

This is expected. By default routing is done based on the destination IP. If
that destination IP is routed through a given interface, that's where the
packets will go. Without specific configuration, the restrictions put on the
source IP are not supposed to influence the routing decision.

>    This can be reproduced every time.
> 
>    4.1. Set up a Fedora 38 VM (I am using VirtualBox) that has one NAT
> interface
>         (has Internet access) and one host-only interface (no Internet
> access).
> 
>    4.2. Try to send a request using curl that is bound to the host-only
>         interface using its interface name. It should fail to connect as
>         expected.
>         $ curl --interface enp0s8 icanhazip.com

There you bind the socket to a specific network device. If the packet can't
be routed through this device, the packet can't go out.

>    4.3. Try to send another request, this time bind to the host-only
> interface
>         using its IP address. It will somehow successfully get a response.
>         $ curl --interface 192.168.56.103 icanhazip.com

There you bind the socket to an IP address. You put no restriction on the
network device to use. The system is free to pick the most suitable one.

>    Note: When --interface is specified, curl binds using SO_BINDTODEVICE when
>          given an interface name, and bind(2) when given an IP address.
>          https://github.com/curl/curl/issues/11599#issuecomment-1667391636

SO_BINDTODEVICE and bind(2) are two different things, made for two different
purposes. They're _not_ supposed to work the same way.

Also, note that by IP addresses identify network nodes, not network interfaces.
When you add an IP address on a given interface, you don't bind it to that
interface. It remains reachable from the other interfaces on the same node
(assuming proper routing and no extra isolation is set up).

I think this can be closed as NOTABUG.

Hi Guillaume,

Thanks for replying in such detail.

> Also, note that by IP addresses identify network nodes, not network interfaces.
> When you add an IP address on a given interface, you don't bind it to that
> interface. It remains reachable from the other interfaces on the same node

Hmm, I suppose this makes sense, otherwise routers can't function.

I also did the test over on FreeBSD, and the result was as I originally expected.
Could you provide any insight as to why that is?

As far as I know, most operating systems derived their network API from BSD, so I
(mistakenly?) took that test result as the "definitive" reference.

(In reply to lagoho7 from comment #2)
> I also did the test over on FreeBSD, and the result was as I originally
> expected.
> Could you provide any insight as to why that is?
> 
> As far as I know, most operating systems derived their network API from BSD,
> so I
> (mistakenly?) took that test result as the "definitive" reference.

Well, I have no experience with FreeBSD or any other BSD variant.
So I really have no insight about how things should work there, sorry.