User/dahoehna/honoring inbound rule

[dhoehna]

📖 Description

LXC will now DROP or ACCEPT local packets depending on the value of allowLocalNetwork.

🔗 References

62864412

🔍 Validation

Verified end-to-end on a real Linux host - WSL2 Ubuntu-24.04 (systemd enabled) with LXC 5.0.3 - using the manual harness added in this PR (tests/scripts/run_lxc_local_network_test.sh).

How it was run:

# Linux host (WSL2 Ubuntu-24.04, systemd on): install LXC + bring up the bridge
sudo apt install -y lxc lxc-utils iptables bridge-utils
sudo systemctl enable --now lxc-net          # lxcbr0 (10.0.3.1/24)

# build the LXC backend executable (pinned Rust 1.93)
cd src && cargo build --release -p lxc        # -> src/target/release/lxc-exec

# run the harness as root (builds netcheck static-musl, runs both configs)
sudo ./tests/scripts/run_lxc_local_network_test.sh

For each config the harness launches lxc-exec <config>, waits for the container IP, then dumps the emitted host-side iptables chain MXC-<containerId> and asserts the loopback verb.

Result - [RULE] pass=2 fail=0:

Config	iptables chain	Loopback rule	Expected	Result
allowLocalNetwork: true	MXC-lxc-localnet-allow	-i lo -j ACCEPT	ACCEPT	✅ PASS
allowLocalNetwork omitted (default)	MXC-lxc-localnet-deny	-i lo -j DROP	DROP	✅ PASS

This confirms the LXC backend maps allowLocalNetwork to the correct iptables verb. The harness also reports an informational [BEHAVIOR] connect layer: with the current code the rule is emitted into the host FORWARD chain (hooked -o <veth>), which a host→container connect does not traverse, so it reports reachable for both configs today and will begin distinguishing allow vs deny automatically once the inbound INPUT-path rule lands. Full runbook: docs/lxc-support/testing-allowlocalnetwork.md.

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

📋 Issue Type

• Bug fix
• Feature
• Task

---

GitHub Actions runs the PR validation build automatically. The ADO pipeline
(MXC-PR-Build) is the Azure version of the PR pipeline, kept in parity with the GitHub
Actions build; it runs on merge to main, and Microsoft reviewers with write access can trigger it
on a PR with /azp run. See docs/pull-requests.md.

If the dependency-feed-check check fails on a new dependency, the crate must be added to
the feed before the PR can pass. See docs/pull-requests.md
for the steps.

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull request overview

This PR aims to make the LXC backend honor the cross-platform allowLocalNetwork network policy knob when installing iptables rules, and updates documentation/examples to surface the field.

Changes:

• Updated LXC iptables rule emission to conditionally ACCEPT/DROP traffic based on allowLocalNetwork.
• Documented allowLocalNetwork in the main config schema example and LXC backend docs.
• Added allowLocalNetwork to the sandbox policy v1 JSON example.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/backends/lxc/common/src/network_iptables.rs	Adds allowLocalNetwork-driven ACCEPT/DROP behavior in the iptables chain.
docs/schema.md	Documents allowLocalNetwork in the example config.
docs/sandbox-policy/v1/policy.md	Adds allowLocalNetwork to the policy example payload.
docs/lxc-support/lxc-backend.md	Documents how allowLocalNetwork affects LXC network policy enforcement.

[dhoehna]

@SohamDas2021 can you validate this comment? The roadmap said to add this to the FORWARD chain. I don't know who is correct. Your roadmap, or copilot.

[SohamDas2021]

Are your changes addressing all the requirements in https://microsoft.visualstudio.com/OS/_workitems/edit/62864412/?view=edit?

"When ingress.hostLoopback is "allow", accept connections from host loopback only"

My understanding was that we would need the new config json schema changes to go in first and you will have a subsequent PR to address that?

{
"network": {
"egress": {
"default": "deny",
"allow": [{ "to": [{ "cidr": "140.82.112.0/20" }], "ports": [{ "protocol": "tcp", "port": 443 }] }],
"deny": [{ "to": [{ "cidr": "10.0.0.0/8" }] }]
},
"ingress": { "hostLoopback": "deny" },
"proxy": { "http": "127.0.0.1:8080" }
}
}

[dhoehna]

Are your changes addressing all the requirements in https://microsoft.visualstudio.com/OS/_workitems/edit/62864412/?view=edit?

"When ingress.hostLoopback is "allow", accept connections from host loopback only"

My understanding was that we would need the new config json schema changes to go in first and you will have a subsequent PR to address that?

{ "network": { "egress": { "default": "deny", "allow": [{ "to": [{ "cidr": "140.82.112.0/20" }], "ports": [{ "protocol": "tcp", "port": 443 }] }], "deny": [{ "to": [{ "cidr": "10.0.0.0/8" }] }] }, "ingress": { "hostLoopback": "deny" }, "proxy": { "http": "127.0.0.1:8080" } } }

My changes are against the current schema. I can make a second PR to read ingress.hostloopback when the schema change is merged into main.

If I change the code to read ingress then I can't test this change until the schema goes in.