fix(bwrap): surface allowLocalNetwork settings the Bubblewrap backend cannot honor

[Carlos Alexandro Becker (caarlos0)]

📖 Description

network.allowLocalNetwork — "the sandboxed process may bind()/listen() on local IPs and accept inbound connections" — is a first-class part of the policy surface. It is declared in ContainerPolicy (src/core/wxc_common/src/models.rs), parsed by config_parser.rs, carried on the wire (src/core/wxc_common/src/wire.rs), and honored by two of the three backends:

• Windows maps it to the AppContainer privateNetworkClientServer capability (src/core/mxc_engine/src/policy.rs).
• Seatbelt emits (allow network-inbound (local ip)) (src/backends/seatbelt/common/src/profile_builder.rs).

grep -rn "allow_local_network" src/backends/bubblewrap/ returned zero hits. On Linux the value was validated, transported to the backend, and then dropped on the floor — a silent no-op in a security-relevant control, which is worse than an outright rejection because the policy readback still shows the field as requested.

Why this isn't enforced instead

Bubblewrap has no inbound-only primitive:

• Unprivileged bwrap shares the host network namespace and has no veth interface, so iptables rules cannot be scoped to the sandbox. NetworkIptablesManager already skips its FORWARD hook when there is no veth, precisely to avoid applying host-wide rules.
• seccomp cannot dereference the sockaddr argument to bind(), so an AF_INET-only filter is not expressible. Blocking bind outright would also kill AF_UNIX sockets; blocking listen would still miss UDP servers.

The namespace choice alone therefore decides the outcome, which leaves two mismatches — note the second is in the restrictive direction and was not previously identified:

allowLocalNetwork	Namespace	Outcome before this PR
false (default)	private (--unshare-net)	Satisfied at the sandbox boundary
false	shared with host (defaultPolicy: allow, host lists, or network.proxy)	Restriction silently dropped — the process can bind/listen on host-local addresses
true	private (--unshare-net)	Silently useless — the listener sits in a namespace nothing outside can reach
true	shared with host	Honored

Change

• New pure local_network_diagnostic() in bwrap_command.rs returns the mismatch for the two unhonorable rows; bwrap_runner::spawn_bwrap logs it as a WARNING: at preflight, so the failure is loud rather than silent.
• Extracted the --unshare-net predicate into uses_private_netns(), shared with build_args_classified, so the diagnostic and the argument builder cannot drift apart.
• Documented the per-platform divergence in docs/bwrap-support/bubblewrap-backend.md.

Deliberately a warning, not a rejection. false is the default, so rejecting the shared-namespace case would break every defaultPolicy: "allow" run. And true + --unshare-net is legitimate when a sandbox both serves and connects to its own loopback.

Incidental doc fix

The backend doc claimed --unshare-net leaves "no network stack ... (including loopback)". That is wrong: bubblewrap calls loopback_setup() when unsharing the network namespace, so lo is up inside the sandbox. The doc now says so, and the truth table depends on it being accurate.

Limitations

This does not make Bubblewrap enforce the field — it makes the gap observable. Enforcement would need a privileged network namespace with a veth pair (i.e. the LXC model), which is out of scope for an unprivileged backend.

🔗 References

• Prior art on the same backend for this class of fix (surface an unhonorable policy loudly at preflight instead of failing quietly): feat(bwrap): readable preflight errors when a path isn't in the deny-by-default baseline #507
• Related but distinct, and already closed: Bubblewrap network firewall mode rejects IPv6-resolved hosts (iptables only accepts IPv4) #479 "Bubblewrap network firewall mode rejects IPv6-resolved hosts"
• loopback_setup() on --unshare-net: containers/bubblewrap bubblewrap.c

🔍 Validation

Automated (run from src/; the Bubblewrap runner is #[cfg(target_os = "linux")], so the Linux target was cross-checked from a macOS host):

cargo fmt -p bwrap_common -- --check
cargo test -p bwrap_common                        # 35 passed (was 29)
cargo clippy -p bwrap_common --all-targets -- -D warnings
cargo clippy --target x86_64-unknown-linux-gnu -p bwrap_common --all-targets -- -D warnings

All four pass, with the same results captured as a baseline before the change (no regressions).

Six new unit tests cover the truth table exhaustively. They live in bwrap_command, which is deliberately platform-agnostic, so they execute on every host:

• local_network_denied_under_private_netns_is_not_warned
• local_network_denied_on_shared_netns_warns
• local_network_denied_with_host_rules_warns
• local_network_denied_with_proxy_warns
• local_network_allowed_under_private_netns_warns
• local_network_allowed_on_shared_netns_is_honored

Not yet run: tests/scripts/run_bwrap_all_tests.sh on a Linux host with bwrap installed, to observe the warning end-to-end. The logged line itself is compile-verified for the Linux target but not executed.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)
• If this PR changes Cargo.lock, the dependency-feed-check check passes (see docs/pull-requests.md) — no dependency changes

📋 Issue Type

• Bug fix
• Feature
• Task

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull request overview

Surfaces Bubblewrap’s inability to independently enforce allowLocalNetwork.

Changes:

• Centralizes network namespace selection.
• Adds mismatch diagnostics and truth-table tests.
• Documents Bubblewrap networking limitations.

Show a summary per file

File	Description
bwrap_runner.rs	Logs preflight diagnostics.
bwrap_command.rs	Adds namespace detection, warnings, and tests.
bubblewrap-backend.md	Documents network behavior and limitations.

Review details

Suppressed comments (1)

src/backends/bubblewrap/common/src/bwrap_command.rs:155

• Recommending defaultPolicy='allow' here silently relaxes the independent outbound policy from deny-all to allow-all. A user following this warning to enable inbound service exposure would also grant unrestricted egress. The remediation should state that Bubblewrap cannot independently provide this combination and recommend another backend, or make the outbound tradeoff explicit rather than prescribing full allow.

        (true, true) => Some(
            "WARNING: Bubblewrap: network.allowLocalNetwork=true is confined to the sandbox's own \
             network namespace. defaultPolicy='block' with no host lists and no proxy applies \
             --unshare-net, so a listener inside the sandbox is reachable only from within it, \
             never from the host. Use defaultPolicy='allow' to share the host network namespace.",

• Files reviewed: 3/3 changed files
• Comments generated: 3
• Review effort level: Balanced

[Carlos Alexandro Becker (caarlos0)]

Your reading of the logger plumbing is correct, but the conclusion overstates what this PR changed — and the fix you propose is a different, much larger PR.

logger.log_line("WARNING: ...") is the established mechanism for preflight policy warnings in this codebase. The closest analogue is Bubblewrap's own cooperative-proxy warning at src/core/wxc_common/src/config_parser.rs:918, which tells the caller that defaultPolicy: "block" is not actually enforced for raw-socket clients — a security-relevant no-op warning with byte-for-byte identical visibility characteristics. Same for learningMode (config_parser.rs:714), which warns that AppContainer restrictions are not enforced at all, and the non-existent-path warning at config_parser.rs:367.

So the buffered-logger limitation you describe is real, but it is a property of the logging architecture that predates this change and applies uniformly to every preflight warning mxc emits. This PR moves allowLocalNetwork from not read at all to diagnosable through the same channel every other policy warning uses. That is the whole intent, and it is strictly better than the status quo.

What you are asking for — "propagate preflight warnings through an API/response channel that the CLI and SDK surfaces consume" — means adding a warnings field to ScriptResponse (src/core/wxc_common/src/models.rs:748, which has no such field today) and threading it through lxc-exec/wxc-exec, mxc-sdk, mxc_ffi's MxcRunResult, the C# SDK, and the TypeScript SDK. That is a cross-cutting API change affecting every backend and all three language bindings. Doing it here would bury a scoped Bubblewrap fix inside an SDK-surface redesign, and it should be decided on its own merits with maintainer input.

Not resolving this thread — leaving it open deliberately so a maintainer can weigh in on whether the warnings channel is wanted as a follow-up. Happy to file it as a separate issue if that is the preference.

[Copilot]

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (1)

src/backends/bubblewrap/common/src/bwrap_command.rs:149

• The warning omits host rules as a reason the sandbox shares the host namespace, even though uses_private_netns requires both host lists to be empty and the new host-rules test reaches this branch. For a request with blockedHosts, the suggested “block with no proxy” configuration still does not apply --unshare-net, so the remediation is misleading. Mention host rules in both the cause and remedy.

            "WARNING: Bubblewrap: network.allowLocalNetwork=false is not enforced while the \
             sandbox shares the host network namespace (defaultPolicy='allow' or network.proxy). \
             The sandboxed process can still bind, listen and accept on host-local addresses. For \
             an unreachable sandbox use defaultPolicy='block' with no proxy, which applies \
             --unshare-net.",

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Balanced