UAC dialog for "current user is not the hyper-v admin group" should be on behalf of devhome, not powershell
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
- Get machine in state to throw "current user is not in the hyper-v admin ..." warning
- Click add user
- 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_x64__8wekyb3d8bbwe (Dev Home GitHub Extension (Canary)) Microsoft.Windows.DevHomeAzureExtension.Canary_0.1000.530.0_x64__8wekyb3d8bbwe (Dev Home Azure Extension (Canary)) Microsoft.Windows.DevHome_0.1501.533.0_x64__8wekyb3d8bbwe (Core Widget Extension) Microsoft.Windows.DevHome_0.1501.533.0_x64__8wekyb3d8bbwe (Hyper-V Extension) Microsoft.Windows.DevHomeGitHubExtension_0.1500.533.0_x64__8wekyb3d8bbwe (Dev Home GitHub Extension (Preview)) Microsoft.Windows.DevHome.Canary_0.1501.547.0_x64__8wekyb3d8bbwe (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
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.
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.
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.
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.