fix(exec-approvals): reject Allow rules with absolute file paths

[AlexAlves87]

Summary

ValidateExecApprovalRules accepted Allow rules whose pattern was an absolute file path (e.g. C:\Users\Public\evil.exe, \?\C:\evil.exe). A local process that obtained the MCP bearer token could use system.execApprovals.set to whitelist an attacker-controlled binary, then invoke it via system.run — a two-step local EoP.

The existing validator already blocked all-wildcard and dangerous-fragment patterns. This closes the gap on specific-path Allow rules.

Changes

• SystemCapability.cs: add check in ValidateExecApprovalRules — rejects Allow patterns that start with a drive root (X:\, X:/) or a UNC/long-path prefix (\)
• CapabilityTests.cs: add ExecApprovalsSet_RejectsAbsolutePathAllowRules theory covering drive-rooted, forward-slash, UNC, and long-path namespace patterns

Fixes #347.

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

[shanselman]

This is the right security direction, but the validator still appears bypassable with quoted absolute paths.

ValidateExecApprovalRules trims and lowercases the pattern, then checks normalized[0] for a drive letter or normalized.StartsWith(@"\\"). A pattern like "C:\Users\Public\evil.exe" starts with a quote, so it is accepted even though it still whitelists a specific absolute binary path. The same applies to quoted UNC/long-path forms.

Suggested fix: strip one layer of matching surrounding quotes before the absolute-path check, and add test cases for at least:

• "C:\Users\Public\evil.exe"
• 'C:\Users\Public\evil.exe'
• "\\server\share\tool.exe"
• "\\?\C:\evil.exe"

I would also consider forward-slash UNC/namespace forms if the command policy accepts them (//server/share/tool.exe, //?/C:/evil.exe).

[AlexAlves87]

Thanks for catching the quoted-path bypass! Added quote stripping before the absolute-path check, and covered all the cases you mentioned — unquoted and quoted drive paths, UNC and long-path prefix forms, single-quoted variants, and the forward-slash equivalents.