Runner protocol authorization policy is implicit in router composition and easy to bypass

[Bnjoroge1]

Severity

P2 / medium security maintainability

Review baseline

0bd0e314696e520aa47620cbe8f008d010e01e57

Summary

Authorization requirements for the runner protocol are currently encoded indirectly through router nesting plus a mixture of handler-local checks and non-rejecting identity middleware.

The server exposes many aliases for the same logical operations (native, GHES org-prefixed, /runner/server, Azure DevOps-compatible, broker and Results/Twirp variants). Some aliases live under require_protocol_bearer, some rely on handler checks, and some are intentionally public.

This makes it difficult to audit whether every alias has the same capability policy. The critical registration bypass tracked separately is an example of the failure mode.

Recommended remediation

Introduce a declarative route/capability manifest that records, for every runner-facing endpoint:

method + canonical operation
all route aliases
required credential/capability type
required identity binding (runner/session/plan/job)
TCP exposure allowed?
guest SocketSurface exposure allowed?

Use the manifest to either build the router or assert the router configuration in tests.

Add exhaustive negative tests that enumerate every alias and verify:

• unauthenticated behavior;
• wrong token class behavior;
• same-class/wrong-identity behavior;
• guest control-socket accessibility;
• consistency among native/GHES/AzDO aliases.

Acceptance criteria

• Every protocol route alias has an explicit documented capability requirement.
• Tests fail when a new alias is added without an authorization policy.
• Equivalent aliases cannot silently diverge in auth behavior.
• Guest-socket exposure is explicitly tested rather than inferred from path prefixes.