fix(sandbox): make DNS and delivery work under gVisor, and bind a runsc job that the netns plan never did

crates/maxplayer-core/examples/render_host_plan.rs

@@ -0,0 +1,42 @@
+//! Prints the **host-side** iptables plan [`HostPolicy`] would hand its applier, for gate evidence.
+//!
+//! Sibling of `render_net_plan`, and it exists for the same reason: a gate script must install the
+//! rules the PRODUCT renders, never rules a script author transcribed. A transcription drifts the
+//! moment the policy changes, and the gate then keeps passing against a firewall the product no
+//! longer builds — the exact failure these gates exist to catch.
+//!
+//! It matters more here than for the namespace plan. The host plan lands in chains that are shared
+//! with every other container on the daemon, so a hand-written approximation of it in a script is
+//! not just drift, it is a rule keyed to the wrong source touching someone else's traffic.
+//!
+//! ```text
+//! cargo run -p maxplayer-core --example render_host_plan -- 172.18.0.2
+//! cargo run -p maxplayer-core --example render_host_plan -- 172.18.0.2 --teardown
+//! ```
+//!
+//! Arguments: the job namespace's address, then optionally `--teardown` for the exact inverse plan.
+
+use maxplayer_core::sandbox_net::HostPolicy;
+use maxplayer_core::sandbox_netns::{host_install_stdin, host_teardown_stdin};
+
+fn main() {
+    let mut args = std::env::args().skip(1);
+    let Some(job_addr) = args.next() else {
+        eprintln!("usage: render_host_plan <job_addr> [--teardown]");
+        std::process::exit(2);
+    };
+    let teardown = match args.next().as_deref() {
+        None => false,
+        Some("--teardown") => true,
+        Some(other) => {
+            eprintln!("unknown argument {other:?} — expected --teardown or nothing");
+            std::process::exit(2);
+        }
+    };
+
+    let policy = HostPolicy { job_addr };
+    let (plan, count) =
+        if teardown { host_teardown_stdin(&policy) } else { host_install_stdin(&policy) };
+    eprintln!("# {count} rules ({})", if teardown { "teardown" } else { "install" });
+    print!("{plan}");
+}

crates/maxplayer-core/examples/render_net_plan.rs

@@ -0,0 +1,33 @@
+//! Prints the iptables plan [`NetPolicy`] would hand its sidecar, for gate evidence.
+//!
+//! This exists so the gVisor gate scripts install the rules the PRODUCT renders rather than rules a
+//! script author transcribed by hand. A transcription drifts the moment the policy changes and the
+//! gate keeps passing against a firewall the product no longer builds — which is the exact failure
+//! the gates are supposed to catch.
+//!
+//! ```text
+//! cargo run -p maxplayer-core --example render_net_plan -- 172.18.0.1 1.1.1.1
+//! ```
+//!
+//! Arguments: the namespace gateway, then every resolver the job is allowed to reach on port 53.
+
+use maxplayer_core::sandbox_net::{NetPolicy, PortRange};
+use maxplayer_core::sandbox_netns::plan_stdin;
+
+fn main() {
+    let mut args = std::env::args().skip(1);
+    let Some(gateway) = args.next() else {
+        eprintln!("usage: render_net_plan <gateway> [resolver ...]");
+        std::process::exit(2);
+    };
+    let dns_resolvers: Vec<String> = args.collect();
+    let policy = NetPolicy {
+        gateway,
+        proxy_ports: Some(PortRange::new(49200, 49299).expect("a valid fixed range")),
+        log_connections: true,
+        dns_resolvers,
+    };
+    let (plan, count) = plan_stdin(&policy);
+    eprintln!("# {count} rules");
+    print!("{plan}");
+}

crates/maxplayer-core/src/home.rs

@@ -320,6 +320,20 @@ pub struct SandboxConfig {
     /// not name, or to carry a gateway base-URL. Unused under `launcher` mode.
     #[serde(default, skip_serializing_if = "Vec::is_empty")]
     pub forward_env: Vec<String>,
+    /// `docker` mode: the DNS resolver ADDRESSES a contained job's `/etc/resolv.conf` names.
+    /// Omitted ⇒ the host's own upstream resolvers are discovered and used; a host that names none
+    /// refuses to run jobs rather than picking a public resolver nobody chose.
+    ///
+    /// This exists because docker's embedded resolver at `127.0.0.11` is unreachable from a gVisor
+    /// sandbox — measured, with a runc control that succeeds on the identical image and network —
+    /// and because `docker run --dns` does not change what the daemon writes into a container on a
+    /// user-defined network. Addresses only, never hostnames: resolving the resolver is the problem
+    /// being fixed. A loopback address is refused for the same reason `127.0.0.11` fails.
+    ///
+    /// Each address named here is opened by the job's egress policy on port 53 and nothing else,
+    /// as a single host (`/32`, or `/128` for v6) — never a subnet.
+    #[serde(default, skip_serializing_if = "Vec::is_empty")]
+    pub dns_servers: Vec<String>,
     /// `docker` mode: the container runtime to run the job under (`docker run --runtime <name>`).
     /// Omitted ⇒ the daemon's default runtime (`runc`). The v1 sandbox posture sets this to `runsc`
     /// on Linux, where the default container shares the host kernel and gVisor is the primary
@@ -329,24 +343,33 @@ pub struct SandboxConfig {
     /// Unused under `launcher` mode.
     #[serde(default, skip_serializing_if = "Option::is_none")]
     pub runtime: Option<String>,
-    /// `docker` mode: the dedicated docker network a job's container joins (`docker run --network`).
-    /// Omitted ⇒ the daemon default (the shared `bridge` network).
+    /// `docker` mode: the **name prefix** for the docker network each job gets to itself.
+    /// Omitted ⇒ no containment, and the daemon default bridge.
     ///
     /// **Setting this is what turns #797 egress containment on for this seat.** A job launched under
     /// it runs in a network namespace whose rules were installed before the job process existed, and
     /// a job whose containment cannot be established FAILS rather than running exposed. There is no
     /// second step: no root command, and nothing to reinstall after a reboot.
     ///
-    /// Two reasons a *named* network rather than the default bridge:
+    /// **It names, it does not share.** This value is not one bridge every job sits on: each job gets
+    /// `<this>-job-<job_id>`, created before its holder and removed after it. The name still does the
+    /// job it always did — telling this seat's networks from a co-tenant daemon's — and no longer
+    /// puts two jobs on one wire. That changed because of a measurement: with jobs sharing a bridge,
+    /// a gVisor job REACHED a live listener inside another job's namespace and no host rule stopped
+    /// it, two containers on one bridge being switched rather than routed, and switched frames
+    /// entering no iptables chain at all on a host without `br_netfilter`. A network per job leaves
+    /// the job no on-link peer but its own gateway, which is also what makes every other destination
+    /// routed, and therefore visible to the host-side policy that binds a gVisor job at all.
+    ///
+    /// A *named* network rather than the default bridge, for a reason that predates all of that:
+    /// **the seller's own services are not on it.** The rules deny by destination, and the seat's LAN
+    /// and host addresses fall inside those denies, so a job must not share the bridge every other
+    /// container on the box uses.
     ///
-    /// * **The seller's own services are not on it.** The rules deny by destination, and the seat's
-    ///   LAN and host addresses fall inside those denies. A dedicated network keeps a job's traffic
-    ///   off the bridge every other container on the box shares.
-    /// * **DNS keeps working.** On a user-defined network a container resolves through docker's
-    ///   embedded resolver at `127.0.0.11` inside its own netns, so no packet crosses to a host or LAN
-    ///   resolver. On the shared default bridge docker copies the host's `resolv.conf` instead, and if
-    ///   that names a LAN or host resolver then denying the LAN also denies DNS — which presents as
-    ///   "the internet is broken" rather than as a firewall rule.
+    /// DNS does not come from the network. A contained job is handed a generated read-only
+    /// `/etc/resolv.conf` naming real upstream resolvers, because docker's embedded resolver at
+    /// `127.0.0.11` is a daemon-side socket reached by NAT inside the netns and a gVisor sandbox
+    /// terminates loopback in its own netstack, where it never answers. See [`crate::sandbox_dns`].
     ///
     /// See [`crate::sandbox_net`] for what the rules are and [`crate::sandbox_netns`] for how they are
     /// put in force.

crates/maxplayer-core/src/lib.rs

@@ -75,6 +75,10 @@ pub mod runtime_guard;
 /// `wallet`-only, so a default-features test run cannot execute a line of them — the policy is the
 /// part that decides what a stranger's job can reach, and it is compiled and tested on every build
 /// rather than only on the money-path one.
+/// The resolver a contained job can reach, and the `resolv.conf` that names it. Ungated for the
+/// same reason as `sandbox_net`: under gVisor a job that cannot resolve cannot deliver, so the
+/// decision about where its lookups go is policy, and it is compiled and tested on every build.
+pub mod sandbox_dns;
 pub mod sandbox_net;
 /// Putting `sandbox_net`'s policy in force: the holder container that owns the job's network
 /// namespace, and the sidecar that installs the rules into it before the job exists. Unconditional