Skip to content

security: Direction B logon task runs wsl.exe elevated, so the write-capable Windows agent runs as Administrator #65

Closed

Description

@zcsizmadia

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.

Activity

  1. zcsizmadia commented on Sep 6, 2026

    @zcsizmadia
    CollaboratorAuthor

    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 Highest unconditionally, 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.
    • "fall back to loopback TCP when discovery fails" was written when TCP was
      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).
    • "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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions