From: baleti <baleti3266@gmail.com>
To: passt-user@passt.top
Subject: Feature request: option to prevent guest from reaching host external addresses
Date: Sat, 2 May 2026 15:25:17 +0100 [thread overview]
Message-ID: <500da332-7eb2-4523-8d63-ebc1000f81a8@gmail.com> (raw)
Hi,
I'd like to propose a new option for passt, working title --no-map-host,
as a complement to the existing --no-map-gw.
The gap
--no-map-gw prevents the guest from reaching host loopback services via
the gateway address mapping, which is useful. However, there is
currently no mechanism to prevent the guest from reaching services bound
to the host's real external address (e.g. 0.0.0.0:22).
Because passt proxies outbound guest connections as the host user, a
connection from the guest to the host's own external IP is transparently
forwarded — passt opens the socket on the host side and the connection
succeeds. From the perspective of the service being connected to (e.g.
sshd), it appears as a local connection.
A concrete example with a typical setup:
passt -t 2222 --no-map-gw --vhost-user --socket /tmp/passt-vm
ss -tulpn shows:
tcp LISTEN 0.0.0.0:22 sshd
From inside the guest, a compromised or untrusted workload can reach
sshd directly:
ssh user@192.168.1.x # host's external IP, connection succeeds
This also enables VM-to-VM lateral movement when multiple guests share
the same host: each guest can reach the others' forwarded ports via the
host's external IP.
The operator has no indication this is happening. Services bound to
0.0.0.0 are generally considered "LAN-exposed" rather than
"VM-guest-exposed", and this assumption is silently violated.
Proposed option
--no-map-host, which would cause passt to drop or reject TCP/UDP
connections from the guest whose destination matches any of the host's
own configured addresses (the same addresses passt already knows about
for DHCP/NDP assignment purposes).
An alternative spelling --map-host-addr none modelled on
--map-host-loopback none would also be consistent with the existing
option naming.
This would stay entirely within passt's existing socket-layer design and
require no new privileges.
Why this matters for rootless setups
The primary audience for passt is rootless VM deployments where
TAP+bridge (the traditional isolation mechanism) is not available
without privilege. In these setups, passt is the only network layer, so
operators rely on it to provide whatever isolation is possible.
--no-map-gw is a good step in that direction; --no-map-host would close
the remaining obvious gap.
Happy to discuss or test patches. Thanks for the project — it's been
very useful.
Best,
baleti
next reply other threads:[~2026-05-02 14:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-02 14:25 baleti [this message]
2026-05-04 5:41 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=500da332-7eb2-4523-8d63-ebc1000f81a8@gmail.com \
--to=baleti3266@gmail.com \
--cc=passt-user@passt.top \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).