Re: Connecting back to the host through a dummy veth interface

[Felix Rubio <felix@kngnt.org>]

Something more: I see that pasta is binding to 0.0.0.0. This means that, while 
allows other pods to connect to the published port of a container through 
169.254.1.2, it also enables that port to be reachable from the network.

Is there any way to prevent that?

Regards!
Felix

On Sunday, 21 December 2025 11:47:22 Central European Standard Time Stefano 
Brivio wrote:
> On Sat, 20 Dec 2025 15:28:43 +0100
> 
> Felix Rubio <felix@kngnt.org> wrote:
> > Hey Stefano,
> > 
> > Thank you for your answer! I know I can run rootful containers, and that 
then
> > I can access the host's network ns. However, this exposes a number of
> > potential issues:
> > * In case the an attacker manages to break out of the container, gets root
> > * That enables connecting back to the host loopback, but then from that
> > container any service listening to the loopback can be reached as well.
> 
> Sure. That's the whole point behind pasta(1) and rootless containers
> with Podman / rootlesskit. I certainly won't be the one suggesting that
> you'd run anything as root. :)
> 
> > The reason for looking for a way of binding those services to 10.255.255.1 
(so
> > that only exposed services will be in that interface) and running fully
> > rootless, if works, provides a more secure system... in general.
> 
> Indeed.
> 
> > About the mapped ports, I am a bit lost: for what I have tested, running
> > rootless disables the possibility to connect back to the host, right?
> 
> Hah, I see now. No, that's not the case. You can run rootless
> containers and connect to the host from them, in two ways:
> 
> 1. disabled by default in Podman's pasta integration, not what you want:
>    via the loopback interface, see -U / -T in 'man pasta' and
>    --host-lo-to-ns-lo for the other way around.
> 
>    In that case, packets appear to be local (source address is
>    loopback) in the other namespace ("host" or initial namespace for
>    packets from a container, and container for packets from host).
> 
>    This gives you better throughput but making connections appear as if
>    they were local is risky (cf. CVE-2021-20199), so it's disabled by
>    default, and not what I'm suggesting (at least in general)
> 
> 2. what you get as default in Podman: using pasta's --map-guest-addr.
> 
>    The current description of this option in pasta(1) isn't great, hence
>    https://bugs.passt.top/show_bug.cgi?id=132, but the idea is that you
>    will reach the host from the container with a non-loopback address,
>    as if the connection was coming from another host (which should
>    represent the expected container usage).
> 
> So here's an example:
> 
> $ podman run --rm -ti -p 8089:80 traefik/whoami
> 2025/12/21 10:42:16 Starting up on port 80
> 
> [in another terminal]
> $ podman run --rm -ti fedora curl host.containers.internal:8089
> Hostname: ab94f49b5042
> IP: 127.0.0.1
> IP: ::1
> IP: **.***.*.***
> IP: ****:***:***:***::*
> IP: ****::****:****:****:****
> RemoteAddr: 169.254.1.2:46592
> GET / HTTP/1.1
> Host: host.containers.internal:8089
> User-Agent: curl/8.15.0
> Accept: */*
> 
> ...doesn't that work for you? Note that you'll need somewhat recent
> versions of pasta (>= 2024_08_21.1d6142f) and Podman (>= 5.3).


-- 
Felix Rubio