[LXC] Network policy enforcement decided from static config or a failed probe fails open

[dhoehna]

Relevant area(s)

Linux

Brief description of your issue

Two places decide whether a firewall-enforced network policy can be applied
using information that the running container can contradict. Both fail open
rather than closed, and neither logs the downgrade, so a caller that asked for
a default-deny policy can get an unfiltered or partially filtered container and
still receive success.

1. A failed interface probe silently downgrades pre-start enforcement
(src/backends/lxc/common/src/lxc_runner.rs, the Err arm around line 261 and
the unwrap_or(false) around line 294)

configured_net_interfaces() returning Err is collapsed to None. None
then means "not pinnable", which is the same answer the code gives for a
container that genuinely has several interfaces. The pre-start egress install
is skipped, the container starts, and the rules are applied only on the
post-start path after wait_for_network. The comment immediately below the
probe states the requirement this violates: "Install egress before the container
starts, so nothing inside it transmits during an interval MXC already reports as
deny-all." The count > 1 refusal is also skipped entirely when the probe
failed, so an unreadable config bypasses the multi-interface check as well.

2. The veth pin hook takes the first peered interface without verifying it is
the only one (src/backends/lxc/common/src/lxc_bindings.rs, VETH_PIN_SCRIPT
around line 330)

The script uses head -n1 and only fails when there are zero peered
interfaces. Its own doc comment claims it "finds the container's sole peered
interface", but nothing checks sole-ness. The count > 1 refusal that would
otherwise catch this reads the static lxc.net configuration, so it cannot
see an interface created imperatively at runtime by an lxc.hook.start-host
entry that the adopted container already carried — the MXC hook is appended
after those. The static count passes, MXC pins and filters one peer, and the
other continues unfiltered for the lifetime of the container.

Steps to reproduce

For (1):

1. Request a policy where requires_firewall() is true against an LXC container.
2. Make configured_net_interfaces() fail — for example run without the
   privileges lxc-info needs, or point at a container whose config cannot be
   parsed.
3. Observe that the run proceeds: the container starts before any egress rule is
   installed, the rules land only on the post-start path, and the call returns
   success.

For (2):

1. Take an existing container whose config already contains an
   lxc.hook.start-host entry that creates an additional veth at start.
2. Adopt it with a firewall-enforced network policy, so the static lxc.net
   count is 1 and the refusal does not fire.
3. Observe the MXC hook rename and filter one peer while the interface created
   by the pre-existing hook stays unfiltered.

Expected behavior

Both cases fail closed. A probe that could not be read is a refusal when the
policy requires a firewall, not a silent downgrade to post-start enforcement.
The pin hook refuses unless the live namespace contains exactly one peered
interface, rather than selecting the first of several.

Actual behavior

Both cases fail open. Case (1) starts a container the caller believes is
default-deny with unrestricted egress until the post-start path completes, and
skips the multi-interface refusal as well. Case (2) leaves a second interface
permanently unfiltered while reporting success. Neither path warns.

---

Raised by Copilot review on PR #849
(threads on lxc_runner.rs and lxc_bindings.rs); both verified by reading the
code at commit 0289a927. Neither was dynamically reproduced.

Part of #896 — the shared root cause is an enforcement decision made from static
or unavailable information that the running container can contradict.

[github-actions]

Triage summary

Labels already present on issue: Issue-Bug, OS-Linux, Area-Executor-LXC — no new labels needed.

Assigned @SohamDas2021 (Linux / LXC / iptables) and @bbonaby (networking / firewall / iptables) — the issue spans both the LXC backend runner and firewall enforcement.

Needs-Triage removed.

Maintainers: Comment /investigate to check whether this issue or bug is valid against the most current code. Copilot will also produce a report with the changes that will be needed. For a small, unambiguous documentation or test fix, it may also create one draft PR.

Generated by 🏷️ Issue Triage for #975 · sonnet46 · 24.2 AIC · ⌖ 4.12 AIC · ⊞ 7.6K · ◷

[dhoehna]

Follow-up analysis from the PR #849 review thread. This does not change the
two defects above; it identifies the shared cause and two ways to remove it.

Root cause: LXC identifies sandbox traffic by device name

Both defects are symptoms of one design choice. LXC's rules live in the
host's iptables, and they select the container's packets by naming a
network device — the veth. LXC generates that name at container start, so MXC
has to discover a string it does not control, at the right moment, and be right
about it. That lookup is what produces both the discovery race (defect 1) and
the "which interface?" ambiguity (defect 2).

No other backend identifies sandbox traffic this way:

• Bubblewrap installs rules inside the sandbox's own network namespace —
  nsenter --net="$ns" -- iptables -A OUTPUT -j "$chain"
  (bubblewrap/common/src/proxy_network.rs:127-137). Inside that namespace
  every packet on OUTPUT is the sandbox's by definition, so no device name is
  needed. It also hooks the chain into OUTPUT last and signals readiness only
  after every rule is installed, because "the caller releases the workload on
  this signal, so emitting it early would let the workload run with egress wide
  open" (:999-1004). That is the same ordering requirement defect 1 violates,
  solved without a pre-start lookup.
• Bubblewrap, isolated mode uses --unshare-net — no interfaces exist at
  all (bwrap_command.rs:136-141).
• AppContainer matches on the app package SID with SetInterfaces left
  empty, so the rule is correct on every interface
  (appcontainer/common/src/network_manager.rs:378,388).
• windows_sandbox enforces inside the guest with
  netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound
  (windows_sandbox/guest/src/firewall.rs).

Every one of those identifies by containment or by identity. LXC alone
identifies by name, which is the only method requiring a runtime lookup.

Prior art already in this file

network_iptables.rs predates PR #849 and already anticipated the hazard.
allow_missing_veth_interface() exists so that tolerating a missing veth is
opt-in and logged, and its doc states the reason: "an unenforced chain is
indistinguishable from an enforced one otherwise." Defect 1 reaches that same
unenforced state with neither the opt-in nor the log.

Two candidate fixes

1. Name the interface instead of discovering it. liblxc supports
   lxc.net.0.veth.pair, which fixes the host-side veth name
   (lxc.container.conf(5)). The repository has zero occurrences of it, and
   MXC already authors this config — "lxc.net.0 MXC configures for itself"
   (lxc_bindings.rs:1114). Setting it removes the discovery step entirely:
   no probe, no head -n1, no timing window, and no multi-interface ambiguity.
   Caveat: the manpage notes unprivileged containers may have this ignored. The
   LXC path appears to require privilege regardless, since it installs host
   iptables rules, but that has not been tested.
2. Filter inside the container's network namespace, as bubblewrap does.
   LXC already has NsenterRunner for ingress. This needs a check that a
   workload cannot modify rules in its own namespace; bubblewrap's containers
   are unprivileged and LXC's may not be.

Neither candidate has been implemented or tested.

Provenance

The host-side-veth enforcement model is not new in PR #849. Upstream
network_iptables.rs already applies rules to "the container's virtual ethernet
(veth) interface", holds veth_interface: Option<String>, and discovers the
name itself via discover_veth_interface() parsing lxc-info's Link: line.
PR #849 changed only the discovery mechanism, moving it to a pre-start hook.