Hi there,
I was tweaking around pasta and its usage with podman, and I realized
that from pasta guest namespaces it is possible to access host ports
through the address of secondary interfaces on the host.
Say I have two interfaces on host, with eth0 connecting to a gateway
and eth1 connected to another LAN:
> $ # On host
> $ ifconfig eth0
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255
> ...
> $ ifconfig eth1
> eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 192.168.110.1 netmask 255.255.255.0 broadcast 192.168.110.255
> ...
> $ ip route
> default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.2 metric 1024
> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 metric 1024
> 192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.2 metric 1024
> 192.168.110.0/24 dev eth1 proto kernel scope link src 192.168.110.1
If there is some service started on host:
> $ python -m http.server
> Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
From a pasta namespace, it is impossible to access the host ports by
the address of the main interface:
> $ pasta --config-net
> $ # Now in pasta namespace
> $ curl 192.168.1.2:8000
> curl: (7) Failed to connect to 192.168.1.2 port 8000 after 0 ms: Couldn't connect to server
However I found that it is possible to do so by the address of the
secondary interface:
> $ # In same pasta environment as above
> $ curl 192.168.110.1:8000
> <!DOCTYPE HTML>
> <html lang="en">
> ...
Is this an expected behavior? I believe this is a security escape in
the container context, since containerized services can gain access to
unintended resources.
Thanks,
Chaser Huang
--
Kangjing "Chaser" Huang