Feature request: Support UAC-less / commandline authentication

[zadjii-msft]

Users should be able to enter their password at the command line, without a UAC prompt, to elevate their privileges.

Requested by: PowerShell / OpenSSH team, and everyone who's ever used sudo on Linux

Potential issues

Literally any malicious.exe out there can AttachConsole to a sudo process, PeekConsoleInput, and steal the password.

[sirredbeard]

This would be particularly useful for running Windows Containers as unprivileged users (currently ContainerAdministrator with full admin privileges is the default) but then allowing developers and administrators to exec into running containers and obtain elevated privileges for debugging as needed.

[etna]

Users should be able to enter their password at the command line, without a UAC prompt, to elevate their privileges.

Requested by: PowerShell / OpenSSH team, and everyone who's ever used sudo on Linux

Potential issues

Literally any malicious.exe out there can AttachConsole to a sudo process, PeekConsoleInput, and steal the password.

Bad idea, please don't implement it.

That UAC prompt, annoying as it may, is the last chance that a person sitting behind the screen has to evaluate whether he or she really wants to run a command or process with elevated privileges and is a lot more effective at doing so than a password prompt because UAC stops all onscreen activity and grants exclusive focus to the prompt.

I've never liked sudo on Linux and will very much prefer Windows to use its own proper authentication mechanisms (UAC) for elevation than just simply typing a password into a terminal shell.

[mominshaikhdevs]

without this feature alone, sudo is currently completely useless when compared to wsudo.

[FirehawkV21]

Users should be able to enter their password at the command line, without a UAC prompt, to elevate their privileges.
Requested by: PowerShell / OpenSSH team, and everyone who's ever used sudo on Linux

Potential issues

Literally any malicious.exe out there can AttachConsole to a sudo process, PeekConsoleInput, and steal the password.

Bad idea, please don't implement it.

That UAC prompt, annoying as it may, is the last chance that a person sitting behind the screen has to evaluate whether he or she really wants to run a command or process with elevated privileges and is a lot more effective at doing so than a password prompt because UAC stops all onscreen activity and grants exclusive focus to the prompt.

I've never liked sudo on Linux and will very much prefer Windows to use its own proper authentication mechanisms (UAC) for elevation than just simply typing a password into a terminal shell.

A potential fix for this would be to do something similar to what the WSL Windows Hello project does: when it catches a call to sudo, it would show a prompt for the user to authenticate (password, PIN, etc.). Maybe the UAC could be updated to request authentication if the sudo command is triggered.

Link to that project: https://github.com/nullpo-head/WSL-Hello-sudo

[mominshaikhdevs]

Users should be able to enter their password at the command line, without a UAC prompt, to elevate their privileges.
Requested by: PowerShell / OpenSSH team, and everyone who's ever used sudo on Linux

Potential issues

Literally any malicious.exe out there can AttachConsole to a sudo process, PeekConsoleInput, and steal the password.

Bad idea, please don't implement it.
That UAC prompt, annoying as it may, is the last chance that a person sitting behind the screen has to evaluate whether he or she really wants to run a command or process with elevated privileges and is a lot more effective at doing so than a password prompt because UAC stops all onscreen activity and grants exclusive focus to the prompt.
I've never liked sudo on Linux and will very much prefer Windows to use its own proper authentication mechanisms (UAC) for elevation than just simply typing a password into a terminal shell.

A potential fix for this would be to do something similar to what the WSL Windows Hello project does: when it catches a call to sudo, it would show a prompt for the user to authenticate (password, PIN, etc.). Maybe the UAC could be updated to request authentication if the sudo command is triggered.

Link to that project: https://github.com/nullpo-head/WSL-Hello-sudo

that still requires some sort of GUI support. the ask here is to do it in a completely command-lineish way. SO NO.

[parkovski]

The thing about this feature is, if you have ssh enabled with a passwordless key, you already have a security vulnerability since that gives you an admin shell (likely due to the lack of sudo). If you only allow keys with a passphrase, then we're essentially here already. With this feature we could make ssh give you a non-admin session and we're no worse off than before, and better in some cases.

[zadjii-msft]

@parkovski That's exactly the scenario that the OpenSSH folks have been talking to us about. Having the ssh server running as admin always is mental. There's definitely room for us to work better together here.

[Brynyard]

@etna simply barring anyone not connected to a GUI desktop from using any elevated commands on the basis that it is «not secure» is at best disingenious. Particularly if you have any knowledge about the many quirks win32 has, or why they introduced the UAC hack in the first place.

Somehow the rest of the world has managed to find solutions for this, and while arguably not perfect by any means, they’re definetly on par with the UAC gui popup (if not better - the presence of UAC demonstrates some fundamental architectural flaws in the Win32 platform). The reason for there not being a solution for this on Windows already is closely related with the long delay before they (somewhat) eventually started adding support for a PTY (just about 40 years late), it simply hasn’t been in their interest to add support for any non-windows features.

But as MS seem to be on a roll, pushing them to finaly have an official solution for the UAC roadblock (not just another fancy runas like it is currently) should be a high priority.

Apologies for creating a dublicate issue, scanned through the existing issues but managed to miss this rather obvious one ;P

[etna]

@etna simply barring anyone not connected to a GUI desktop from using any elevated commands on the basis that it is «not secure» is at best disingenious. Particularly if you have any knowledge about the many quirks win32 has, or why they introduced the UAC hack in the first place.

Somehow the rest of the world has managed to find solutions for this, and while arguably not perfect by any means, they’re definetly on par with the UAC gui popup (if not better - the presence of UAC demonstrates some fundamental architectural flaws in the Win32 platform). The reason for there not being a solution for this on Windows already is closely related with the long delay before they (somewhat) eventually started adding support for a PTY (just about 40 years late), it simply hasn’t been in their interest to add support for any non-windows features.

But as MS seem to be on a roll, pushing them to finaly have an official solution for the UAC roadblock (not just another fancy runas like it is currently) should be a high priority.

Apologies for creating a dublicate issue, scanned through the existing issues but managed to miss this rather obvious one ;P

Windows IS a GUI-driven operating system, and the vast majority of Windows and Windows Server users and administrators manage their operating systems through the graphical desktop.

Why are we trying to linuxify Windows and making it behave like Linux when it clearly should be doing its own thing, and especially when Linux distributions and users keep demanding that Windows users adapt to their archaic ways?

Windows is not Linux and has no reason to change its architecture or design to fit Linux users. Even if any tools or utilities from Linux are ported over to Windows, they should be modified to work within the existing Windows architecture and design. UAC works well for what it is, is an integral part of Windows, and should remain the method of authorizing permissions or privileges escalations in Windows.

[mominshaikhdevs]

@etna simply barring anyone not connected to a GUI desktop from using any elevated commands on the basis that it is «not secure» is at best disingenious. Particularly if you have any knowledge about the many quirks win32 has, or why they introduced the UAC hack in the first place.
Somehow the rest of the world has managed to find solutions for this, and while arguably not perfect by any means, they’re definetly on par with the UAC gui popup (if not better - the presence of UAC demonstrates some fundamental architectural flaws in the Win32 platform). The reason for there not being a solution for this on Windows already is closely related with the long delay before they (somewhat) eventually started adding support for a PTY (just about 40 years late), it simply hasn’t been in their interest to add support for any non-windows features.
But as MS seem to be on a roll, pushing them to finaly have an official solution for the UAC roadblock (not just another fancy runas like it is currently) should be a high priority.
Apologies for creating a dublicate issue, scanned through the existing issues but managed to miss this rather obvious one ;P

Windows IS a GUI-driven operating system, and the vast majority of Windows and Windows Server users and administrators manage their operating systems through the graphical desktop.

Why are we trying to linuxify Windows and making it behave like Linux when it clearly should be doing its own thing, and especially when Linux distributions and users keep demanding that Windows users adapt to their archaic ways?

Windows is not Linux and has no reason to change its architecture or design to fit Linux users. Even if any tools or utilities from Linux are ported over to Windows, they should be modified to work within the existing Windows architecture and design. UAC works well for what it is, is an integral part of Windows, and should remain the method of authorizing permissions or privileges escalations in Windows.

By that logic, there was no need to even bring sudo to windows at all. Because, Windows' existing per-file permission system was working well.

KEY POINT IS: Windows does NOT HAVE TO be restricted to GUI only, hence the issue has been raised.

[Stanzilla]

I would also love to have support for Windows Hello instead of the UAC prompt or actually for UAC prompts in general.

I already use this in my WSL Ubuntu (https://github.com/nullpo-head/WSL-Hello-sudo) and macOS (https://github.com/artginzburg/sudo-touchid) and having that on Windows as well would streamline my experience a lot.

[gerardog]

I would also love to have support for Windows Hello instead of the UAC prompt or actually for UAC prompts in general.

You have a point, how will UAC evolve? Will Microsoft sudo drive changes on UAC or even replace it?

For example: UAC can already be configured to use Windows Hello, given your webcam supports it. The problem is that UAC lacks configuration and friendliness: (see gerardog/gsudo#153 (comment))
The annoying part is that typing user/password is UAC's default, and takes 2 clicks to enable face recognition ¡on every single elevation!

[Brynyard]

@etna

Windows IS a GUI-driven operating system, and the vast majority of Windows and Windows Server users and administrators manage their operating systems through the graphical desktop.

Why are we trying to linuxify Windows and making it behave like Linux when it clearly should be doing its own thing, and especially when Linux distributions and users keep demanding that Windows users adapt to their archaic ways?

Windows is not Linux and has no reason to change its architecture or design to fit Linux users. Even if any tools or utilities from Linux are ported over to Windows, they should be modified to work within the existing Windows architecture and design. UAC works well for what it is, is an integral part of Windows, and should remain the method of authorizing permissions or privileges escalations in Windows.

Terminal =! Linux, and this is not about "linuxifying" anything (whatever that means). The wast majority of Windows server admins use RDP, quite simply because Windows doesn't support anything else, not because it is terribly convenient, easy to set up or well suited to remote administration, and this is why Microsoft over the last few years a) has lost a lot of market share in the server segment and b) is working hard on reinventing the console with it's own interpretation (you might have heard about PowerShell?).

There's no reason to do any fundamental changes to the architecture (other than possibly improve safety in general if they intend to deploy it in more remote locations), and the hardline attitude that a image sent over the wire, with a corresponding mouse click event sent in return should be the only way to respond to an auth challenge is, I'm sorry to be blunt, stupid.

Luckily the engineers at MS aren't silly, they've already implemented plenty of auth methods not involving images being sent back & forth, but my hope was that this would be considered a key feature, as right now, a console tool for privilege escalation that requires you to also have a RDP session running just to click on the fancy UAC GUI windows is a bit counterproductive.

[nrclark]

Yes, @Brynyard has it exactly right. Nobody is saying that we shouldn't authenticate. But it's pretty annoying to need a graphical pop-up to do it.

Why not let us enter our password at the command-line? If I'm SSHed into a machine, why should I also need remote-desktop? How is clicking a GUI box more secure than entering my password, or maybe a PIN number or something?

Text-based interfaces are much more convenient than RDP if I have to deal with a whole bunch of machines. It could even be an opt-in feature for admins that want it.

[MouriNaruto]

I think using UAC-less authentication is OK for Windows-style Sudo if uses the password generated by Time-based one-time password (TOTP) and HMAC-based one-time password (HOTP) as mandatory like using the Two-factor authentication.

It will reduce the potential risk of emulating user input to bypass the password authentication window.

Note: I think the way like the Azure CLI in Linux is also acceptable.

Kenji Mouri

[mikeggh]

The level of secureness should be configurable at least. I am sure that some people would rather their machines be more secure, and others would rather have convenience. If Microsoft is investing into a real window's alternative for sudo, then I'd hope that it would cover each of the points people have expressed here in a final product.

I feel that the Runas utility is extremely annoying to use on any effective scale, and have always needed custom code to have any reasonable expectation of recovering from possible error scenarios. Sudo is a chance to solve all of those obstacles. Sudo's NOPASSWD option is something I definitely use on some machines, and would never consider on others.

Either way, It'll be exciting to see where it leads..

[zadjii-msft]

I'm a big proponent of making everything configurable. In my opinion, having a commandline-based auth method probably won't be the default. Especially not the *nix-style prompt, since literally any console application running at medium-IL could very easily sniff your password with a AttachConsole & PeekConsoleInput.

That being said, I'm also big on "users should be able to just get things done". So, I'd probably implement this with options to let users opt-in for convenience at the cost of security posture.

[nrclark]

@zadjii-msft could an SSH-style keypair get the job done? That could provide some security without requiring a sniffable password, and would still be automation-friendly.

[Brynyard]

@zadjii-msft the boat for securing anything running in Win32 userland has long since sailed, so if the goal is to also ensure safety on that level you'd have to require an integration with external auth using a keypair, TOTP or similar.

Though, one of the main the reasons I (+more) request this is not because we need this locally. Besides, requiring an external signing device isn't that outlandish (it's been the default at my office for a while now, and I don't foresee this going away).

[mominshaikhdevs]

the boat for securing anything running in Win32 userland has long since sailed, so if the goal is to also ensure safety on that level you'd have to require an integration with external auth using a keypair, TOTP or similar.

Nope. There's something called LowIL/AppContainers.

1. https://github.com/microsoft/win32-app-isolation/.
2. https://blogs.windows.com/windowsdeveloper/2023/06/14/public-preview-improve-win32-app-security-via-app-isolation/.
3. https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer/.

the Windows Input team, after implementing a specialized AppContainer for auth purposes, will provide APIs for this "commandline based auth method", the commandline based auth process(which is providing passwords) itself will run in LowIL/AppContainers. So, AttachConsole and PeekConsoleInput won't have access in that particular process. Thus the passwords WON'T BE STOLEN.

[mscottford]

@zadjii-msft

Especially not the *nix-style prompt, since literally any console application running at medium-IL could very easily sniff your password with a AttachConsole & PeekConsoleInput.

Since this is the scenario that is causing the concern, would a better solution be to address it as a root cause? Perhaps require much higher privileges for running such a process? Or disable being able to do so by default? Food for thought.

[eveloki]

@SteveSyfuhs any ideas？

[SteveSyfuhs]

@SteveSyfuhs any ideas？

Thanks, I hate it. :) App isolation provides a great guarantee that other things can't capture the password, but you have to be careful with the thing calling into the isolated app. If you have a console window running as standard user and that's piping the input stream to the low privileged process, I suspect hooking the normal process will still give you the ability to look at the stream. It's plausible app isolation already solves this problem, but that would be something to ask them.

Ultimately, typing your password into a process gives that process your credential. There is no two ways about it. Additionally, what's to prevent anyone from mimicking the sudo prompt to collect the credential (albeit what's to stop it from prompting Cred UI too)?