install WFP filters for Windows sandbox setup#20101
Conversation
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3a320a8db5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eb66c8fad6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| install_wfp_filters( | ||
| &payload.codex_home, | ||
| &payload.offline_username, | ||
| payload.otel.as_ref(), | ||
| |message| { | ||
| let _ = log_line(log, message); | ||
| }, | ||
| ); |
There was a problem hiding this comment.
Fail setup when WFP filter installation fails
This call ignores WFP install failures, so full setup can succeed without any WFP rules applied. Since setup version/marker are persisted earlier during user provisioning, affected users are considered up-to-date and will not automatically rerun full setup to retry filter install. A transient WFP error can therefore leave the sandbox permanently missing the new egress protections.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
I think this should hard-block setup, not just emit telemetry. The new filters are part of the offline sandbox boundary, and provision_sandbox_users has already written the v6 marker before this call, so treating WFP failure as non-fatal creates a sticky degraded state: future runs think setup is current and never retry full setup.
Suggested fix: make install_wfp_filters(...) return Result<usize> or a typed setup result, propagate failure from run_setup_full, add a HelperWfpFilterInstallFailed setup error code, and add a regression test/marker proof that a WFP install failure prevents a successful setup marker. If we intentionally want a degraded mode, the marker needs to record wfp_filters_installed=false and force full setup retry before offline sandbox use; but for this PR I would fail closed.
There was a problem hiding this comment.
yeah, I'm just paranoid about it, especially after the recent bug to Windows Firewall rules that caused the setup to fail for all users. Combined with the fact that we can't do a statsig rollout in the CLI.
My thought was to have it fail silently at first and then make it a hard failure later. If there is a bug for some users, it will move them from "working elevated setup" to some state where they need to re-run the elevated setup and it fails every time. I think it would break codex for them, because we don't have the right UX for this kind of "marker driven re-run of setup"
Lemme think about it
There was a problem hiding this comment.
for now I'm going to leave it like this. I'm planning some improvements to the whole "setup marker" system and if I see that this is failing for users, I will build it.
Summary
This PR installs a first wave of WFP (Windows Filtering Platform) filters that reduce the surface area of network egress vulnerabilities for the Windows Sandbox.
What WFP is
Windows Filtering Platform (WFP) is the low-level Windows networking policy engine underneath things like Windows Firewall. It lets privileged code install persistent filtering rules at specific network stack layers, with conditions like "only traffic from this Windows account" or "only this remote port," and an action like block.
In this change, we create a Codex-owned persistent WFP provider and sublayer, then install block filters scoped to the Windows sandbox's offline user account via
ALE_USER_ID. That means the filters are targeted at sandboxed processes running as that account, rather than globally affecting the host.Initial filter set
We are starting with 12 concrete WFP filters across a few high-value bypass surfaces. The table below describes the filter families rather than one filter per row:
ALE_AUTH_CONNECTandALE_RESOURCE_ASSIGNMENT53onALE_AUTH_CONNECT_V4/V6853onALE_AUTH_CONNECT_V4/V6445and139onALE_AUTH_CONNECT_V4/V6For IPv4/IPv6 coverage, the port-based filters are installed on both
ALE_AUTH_CONNECT_V4andALE_AUTH_CONNECT_V6. ICMP also gets both connect-layer and resource-assignment-layer coverage because ICMP traffic is shaped differently from ordinary TCP/UDP port traffic.Validation
cargo fmt -p codex-windows-sandbox(completed with existing stable-rustfmt warnings aboutimports_granularity = Item)cargo test -p codex-windows-sandbox wfp::testscargo test -p codex-windows-sandbox(fails in existing legacy PowerShell sandbox tests becauseMicrosoft.PowerShell.Utilitycould not be loaded; WFP tests passed before that failure)