Phase 2: fallback_detector module for tier selection

[MGudgin]

📖 Description

Adds a pure detection module that produces a TierDecision from policy + runtime probes (BaseContainer API, bfscfg.exe presence, WRITE_DAC), plus security hardening for the Tier 2 (AppContainer + BFS) execution path.

Module

• Three-tier model: BaseContainer / AppContainerBfs / AppContainerDacl
• allow_dacl_fallback=false blocks any tier requiring host DACL modification (including T1/T2 deny-augmentation)
• MXC_FORCE_TIER injection seam (debug builds only) for testing
• Pure module: no Logger dependency, no telemetry emission. Phase 4 wires this into the dispatcher.

🛡️ Security hardening

1. Environment-driven Tier 2 → Tier 3 downgrade. The original probe read the SystemRoot env var when locating bfscfg.exe, letting an attacker who could influence the process environment (parent process, persisted user env, service definition) force a silent demotion to Tier 3 (DACL) even with the real binary in System32. Release builds now resolve via GetWindowsDirectoryW exclusively — the OS populates it from boot configuration, not the process environment.

2. Executable-search-order hijacking. FileSystemBfsManager previously invoked CreateProcessW with lpApplicationName = NULL and a bare bfscfg.exe command line, exposing the standard image-dir → CWD → System32 → System → Windows → PATH search order. An attacker who could drop bfscfg.exe next to wxc-exec.exe, in CWD, or earlier on PATH would have their binary executed as the BFS broker regardless of what the probe concluded. find_bfscfg_exe now returns the absolute path resolved at probe time; FileSystemBfsManager passes it as lpApplicationName so Windows loads exactly that binary and skips the search order.

Probe and execution share one resolution via TierDecision.bfscfg_path — single source of truth, no TOCTOU gap between tier decision and broker invocation.

Debug-only test seam: MXC_BFSCFG_PATH overrides resolution under #[cfg(debug_assertions)]. Release builds never read it, so it cannot be used as an attack vector in production.

A follow-up TODO in fallback_detector.rs flags BaseContainerRunners LoadLibrary on processmodel.dll as the next surface to audit for the same DLL-search-order family of attacks (Tier 1 surface).

🔗 References

Stacked on top of #293 (phase1_integrate → phase1d).

🔍 Validation

• cargo fmt --all -- --check clean
• cargo clippy --workspace --all-targets -- -D warnings clean
• cargo test -p wxc_common — 357 tests pass (16 fallback_detector incl. 4 new for the MXC_BFSCFG_PATH seam; 8 filesystem_bfs incl. 1 new for absolute-path quoting)
• End-to-end coverage lives in Win25H2Safe-Tests.ps1 in phase5 (held)

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a new fallback_detector module that selects an IsolationTier (BaseContainer / AppContainerBfs / AppContainerDacl) based on ContainerPolicy plus runtime probes (BaseContainer API, bfscfg.exe, WRITE_DAC). Pure module with a debug-only MXC_FORCE_TIER test seam; no logging or telemetry.

Changes:

• New fallback_detector module with detect(), TierDecision, FallbackError, and runtime probes.
• Promoted BFSCFG_EXE to pub(crate) so the detector can reuse the constant.
• Registered the new module in wxc_common's lib.rs under cfg(target_os = "windows").

Show a summary per file

File	Description
src/wxc_common/src/lib.rs	Exposes the new fallback_detector module on Windows.
src/wxc_common/src/filesystem_bfs.rs	Widens visibility of BFSCFG_EXE to pub(crate) for reuse.
src/wxc_common/src/fallback_detector.rs	New pure tier-selection module with probes, force-tier seam, and unit tests.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 5

[jsidewhite]

delete_app_container_profile

Annoying the cleanup function isn't in the same file as the setup function (AC_runner.rs).

[jsidewhite]

Is this a real threat? If an attacker can manipulate the environment of wxc-exec.exe, then it's it's already in.

Is this merely defense in depth?

[jsidewhite]

ohhh it's moreso this,

preventing
    /// executable-search-order hijacking by an attacker who can plant a
    /// rogue `bfscfg.exe` next to `wxc-exec.exe`

[jsidewhite]

can't you use the path crate?

use std::path::Path;

let p = Path::new(r"C:\Windows").join("System32").join("kernel32.dll");

or

use std::path::PathBuf;

let mut path = PathBuf::from(r"C:\");
path.push("Windows");
path.push("System32");
path.set_extension("dll");

println!("{}", path.display());

[jsidewhite]