public inbox for passt-user@passt.top
 help / color / mirror / Atom feed
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


             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).