You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
security: Direction B logon task runs wsl.exe elevated, so the write-capable Windows agent runs as Administrator #65
From the comprehensive pre-release review of main @ e7ffab6 (four independent Fable 5 reviewers: security, performance, correctness, release readiness). Deferred past v0.9.0.
install.ps1 registers the Direction B task with RunLevel Highest (needed only for hcsdiag list VM-GUID discovery). Interop processes launched from an elevated wsl.exe are elevated, so wsldrived.exe --root applies write-through mutations under winRoot with admin rights. Anything in the distro holding the token gets admin-level write access under winRoot.
Fix: keep the task Limited and discover the GUID another way (small elevated helper, cached GUID with --vm-guid, or fall back to loopback TCP when discovery fails); at minimum launch the Windows agent via a Limited task rather than interop.
Partly fixed, and the rest may not need fixing at all
Two things have changed since this was written.
#109 removes the elevation wherever it was never needed. The Direction B
logon task was registered RunLevel Highestunconditionally, including with -NoHvsocket where the mount talks plain TCP and there is no hcsdiag lookup
to need Hyper-V admin for. So on that path the elevation — and with it the
administrator-rights write-through under -WinRoot this issue describes — was
pure cost. It is now conditional on the mount actually using hvsocket.
The hvsocket path itself may be going away (#110). Direction B was unusable
over loopback TCP on this machine — seconds per round-trip, which is the entire
reason hvsocket exists here. On WSL 2.7.8.0 a round-trip is 0.224 ms, and
Direction B end-to-end over plain TCP measures 225 ms, within noise of the
233 ms serving floor taken with the boundary deliberately removed. The transport
is no longer costing anything worth measuring.
What that leaves
The suggestions in the original report do not survive contact:
"cached GUID with --vm-guid" does not work. The WSL VM GUID is
regenerated per boot, and the logon task runs at boot, so a value captured at
install time is stale exactly when it is needed.
"a small elevated helper" or launching the Windows agent from a separate
Limited task remain the only ways to keep hvsocket and drop the agent's
privileges. Both add a second component and its lifetime coupling.
So the decision this issue needs is really #110's: if Direction B defaults to
TCP on WSL versions where the relay is fast, this problem disappears for
essentially everyone, and the elevated path survives only as a fallback for
older WSL — where it would still be worth doing the separate-Limited-task work,
but for a much smaller audience.
Leaving this open, because the hvsocket path still elevates and #109 does not
change that. But I would settle #110 first rather than build the second
mechanism now.
Activity
zcsizmadia commentedon Sep 6, 2026
Partly fixed, and the rest may not need fixing at all
Two things have changed since this was written.
#109 removes the elevation wherever it was never needed. The Direction B
logon task was registered
RunLevel Highestunconditionally, including with-NoHvsocketwhere the mount talks plain TCP and there is nohcsdiaglookupto need Hyper-V admin for. So on that path the elevation — and with it the
administrator-rights write-through under
-WinRootthis issue describes — waspure cost. It is now conditional on the mount actually using hvsocket.
The hvsocket path itself may be going away (#110). Direction B was unusable
over loopback TCP on this machine — seconds per round-trip, which is the entire
reason hvsocket exists here. On WSL 2.7.8.0 a round-trip is 0.224 ms, and
Direction B end-to-end over plain TCP measures 225 ms, within noise of the
233 ms serving floor taken with the boundary deliberately removed. The transport
is no longer costing anything worth measuring.
What that leaves
The suggestions in the original report do not survive contact:
--vm-guid" does not work. The WSL VM GUID isregenerated per boot, and the logon task runs at boot, so a value captured at
install time is stale exactly when it is needed.
unusably slow, so it read as a bad trade. On current WSL it is not a fallback,
it is arguably the better default (Direction B may no longer need the Hyper-V socket transport: TCP round-trip is now 0.224 ms #110).
Limited task remain the only ways to keep hvsocket and drop the agent's
privileges. Both add a second component and its lifetime coupling.
So the decision this issue needs is really #110's: if Direction B defaults to
TCP on WSL versions where the relay is fast, this problem disappears for
essentially everyone, and the elevated path survives only as a fallback for
older WSL — where it would still be worth doing the separate-Limited-task work,
but for a much smaller audience.
Leaving this open, because the hvsocket path still elevates and #109 does not
change that. But I would settle #110 first rather than build the second
mechanism now.