Group Policy + admin setting for environment variable expansion in CLI arguments

[denelon]

Relevant area(s)

WinGet CLI

Description of the new feature / enhancement

If we decide to support environment variable expansion in user-supplied CLI arguments (see #6388 and #5551), the capability must be off by default and gated behind an admin setting with a corresponding Group Policy, so IT organizations can control the default/enforced behavior. This issue tracks creating/implementing that Group Policy (and the admin setting it backs).

Context: expanding ambient environment variables in argument values before execution has security implications — an ambient or poisoned environment could redirect an install location or inject installer arguments, which is sharper when winget runs elevated. The capability should therefore be disabled by default and centrally controlled.

This is a sub-issue of #6388 and is contingent on a go/no-go product decision on env-var expansion (tracked with #5551).

Proposed technical implementation details

• Add an admin setting to enable environment variable expansion for CLI arguments.
• Add a Group Policy (ADMX + registry) entry so IT can set the default/enforced behavior.
• Apply consistently across the relevant arguments (--location, --override, --custom, log location, etc.).
• Perform the expansion centrally during input-argument processing rather than in individual workflow tasks.

[eugenesvk]

Just a note that the admin/policy restrictions should ideally be scoped to only those env vars / winget invocation cases where there is a geniune security risk. For example, if %SystemDrive% is already an admin-gated env var, then it should be safe to use it without extra policies.
Similarly, if WinGet is launched as non-admin, then it might be fine to expand variables to non-admin-protected paths?

[Trenly]

Just a note that the admin/policy restrictions should ideally be scoped to only those env vars / winget invocation cases where there is a geniune security risk. For example, if %SystemDrive% is already an admin-gated env var, then it should be safe to use it without extra policies. Similarly, if WinGet is launched as non-admin, then it might be fine to expand variables to non-admin-protected paths?

This would be true except for the ability for non-elevated processes to override the environment variables within their current scope. Take this PowerShell example:

Even though that process is not elevated, I can still modify the environment for future commands run in that context. This would mean that any commands run in that context would use the environment varible that I set instead of the machine's default. Granted, the modification only applies in that specific process context and doesn't persist to the whole machine, but there's nothing to say that a malicious payload couldn't modify the session that winget is running in

[eugenesvk]

only applies in that specific process context and doesn't persist to the whole machine,

Yes, that's what I meant and tried to do.

there's nothing to say that a malicious payload couldn't modify the session that winget is running in

In that case could it not simply modify the arguments?
But not a security expert, so if it's insecure, oh well.