UAC dialog for "current user is not the hyper-v admin group" should be on behalf of devhome, not powershell

[crutkas]

Dev Home version

0.1501.547.0

Windows build number

10.0.22631.3874

Other software

OS Build Version: 10.0.22631.3874.amd64fre.ni_release.220506-1250 .NET Version: .NET 8.0.6

Steps to reproduce the bug

1. Get machine in state to throw "current user is not in the hyper-v admin ..." warning
2. Click add user
3. UAC Dialog for PowerShell pops up

Expected result

Dev Home should the UAC dialog as that is who the user is assuming is performing the action, not PowerShell

Actual result

PowerShell has UAC dialog

Included System Information

CPU: Intel(R) Core(TM) Ultra 7 165H Physical Memory: 31.64GB (12.76GB free) Processor Architecture: x64

Included Extensions Information

Extensions: Microsoft.Windows.DevHomeGitHubExtension.Canary_0.1500.530.0_x648wekyb3d8bbwe (Dev Home GitHub Extension (Canary)) Microsoft.Windows.DevHomeAzureExtension.Canary_0.1000.530.0_x648wekyb3d8bbwe (Dev Home Azure Extension (Canary)) Microsoft.Windows.DevHome_0.1501.533.0_x648wekyb3d8bbwe (Core Widget Extension) Microsoft.Windows.DevHome_0.1501.533.0_x648wekyb3d8bbwe (Hyper-V Extension) Microsoft.Windows.DevHomeGitHubExtension_0.1500.533.0_x648wekyb3d8bbwe (Dev Home GitHub Extension (Preview)) Microsoft.Windows.DevHome.Canary_0.1501.547.0_x648wekyb3d8bbwe (Core Widget Extension) Microsoft.Windows.DevHome.Canary_0.1501.547.0_x64__8wekyb3d8bbwe (Hyper-V Extension)

Widget Service: MicrosoftWindows.Client.WebExperience_524.18000.0.0_x64__cw5n1h2txyewy

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• Can't add standard user account to Hyper-V Administrator group if elevating using a separate administrator account (#3112), similarity score: 0.77

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[huzaifa-d]

This is by design. UAC from Dev Home would mean that Dev Home would have to be elevated. And elevated Dev Home doesn't play well with certain COM calls.

[crutkas]

Use a CLI argument into DevHome as admin to do the upgrade, when done close the instance. The UAC would be from dev home which is what is doing the command, not a random PS window that is asking to elevate. UX, if needed, would be as simple as a "Doing Work XYZ" window.

[DHowett]

For what it's worth, the actual security risk posed by elevating a random powershell -command {A BUNCH OF TEXT THAT NOBODY IS GOING TO READ} is that we train users--EVEN the ones who actually read our security prompts--that they cannot safely audit what they are elevating. They have no chance of opening up that "More Info" link in the elevation dialog and reading what it's doing.

Therefore, they have to trust it.

And when they blindly trust it, malware can get them to do much worse stuff.

---

I will also offer this. DevHome runs as Medium IL. Any other Medium IL process can inject into it, even if it's in a Centennial container.

How can you verify that the -Command {bunch of text} has not been tampered with by an attacking process?

Code signing. You code sign the PowerShell script, and force the RemoteSigned -ExecutionPolicy. That way, the user knows what they are elevating and PowerShell rejects it if the code signature fails validation.