Microsoft is testing native Sudo command support for Windows 11. The support for native “Sudo” command was spotted in a leaked Windows Server preview build, accidentally published to the Windows Update servers over the weekend.
↫ Mayank Parmar
It’s kind of wild that something like sudo doesn’t exist in Windows.
Windows has had something like sudo since Windows Vista. It’s called User Account Control (UAC). Per documentation:
> UAC allows all users to sign in their devices using a standard user account. Processes launched using a standard user token may perform tasks using access rights granted to a standard user. …When a user tries to perform an action that requires administrative privileges, UAC triggers a consent prompt. The prompt notifies the user that a change is about to occur, asking for their permission to proceed
Ugh, wish I could edit these comments.
Documentation link: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/
Yes, but read up on what it takes to run something elevated from a batch file.
The TL;DR: is that, if you don’t want to embed an inline snippet of PowerShell or VBScript in your batch file, you’ll have to rely on a third-party tool like elevate.exe, which is basically an aftermarket /usr/bin/sudo.
Windows has had runas for 24 years, which is “something like” sudo.
UAC tried hard to be secure. I know people later say it’s not a security boundary (sigh) but a lot of restrictions were added to ensure that an un-elevated process can’t just send messages to an elevated process and hijack it, and to secure the UAC prompt itself, etc.
With inline sudo, that’s basically impossible to prevent. You now have two processes attached to the same conhost, watching the same keystrokes and output. Any unelevated process can feed input into the elevated process (WriteConsoleInput), monitor interactions with it (PeekConsoleInput), and watch its output (ReadConsoleOutput.)
It’s quite straightforward to implement sudo on Windows. The issue is accepting the security tradeoff. That’s why runas required console processes to launch in a new window so they can’t just mess with each other across what is supposedly a security boundary.
As per @malxau, runas already fills this role, and has for many years.
Or in PowerShell, start-process has alternate user creds built-in.
Runas could allow inline elevation, but it was a deliberate choice not to (and there’s nothing stopping them adding an argument to allow it now while preserving compatible behaviour).
I’m genuinely not sure why there’s a “sudo” being added. It doesn’t even make sense on Windows because the concept of a “superuser” (the “su” in “sudo”) isn’t really present – Administrator is just a default account with specific permissions and group memberships, there’s nothing inherently special about local SID 500 in the way UID 0 is special on Linux/Unix.
If you’re a Linux/Unix user on Windows you’re probably not using the command prompt much anyway, PowerShell has a native implementation already, and if you’re in a WSL shell then sudo already exists. Come to think of it, that’s the only thing that might make sense, allowing real sudo from a WSL 1.x environment to escape the constraints of the Win32 environment user account. However, given WSL 1.x is basically dead, I doubt that’s where it’s intended for use.
The1stImmortal,
Indeed, it seems kind of weird the article doesn’t even mention it.
Microsoft calls WSL2 “native Linux on Windows” – so who knows what they mean by “native sudo”
Obviously too early to know, but it’s possible that this could be a game changer. Depends.
Windows ssh implementation get you a “dumb user” if done by key, you won’t get a ticket to ride on Kerberos. You might as well not be a user at that point.
If their sudo is also “dumb”, you really won’t get any worthwhile privilege elevation (for example).
Microsoft still needs to work on trust paths. I get that they don’t want to have trusts outside of what they provide… emphasis…. by default, but IMHO, their platform would be a lot stronger if such trusts could be established via configuration somehow. In this case for priv elevation.
IMHO, if they do this, it’s only natural to also allow identity by ssh ppk. We’ll see though. Again, doesn’t have to be the default. Microsoft can continue to play in “I don’t integrate with anything” space by default. But if they did open themselves up to some configurable insertion of trusts and elevations, it could be something that makes them more relevant.
chriscox,
I’ve never used windows as an SSH host. You’re saying you can’t do an admin command prompt…is that really true? If that is true then I’d agree that’s kind of useless.
I actually wrote a telnet daemon for windows in one of my first jobs a long time ago. They used it to run “sc” commands on a windows server from other computers.