Introducing Sudo for Windows!
Introducing Sudo for Windows
We’re excited to announce the release of Sudo for Windows in Windows 11 Insider Preview Build 26052! Sudo for Windows is a new way for users to run elevated commands directly from an unelevated console session. It is an ergonomic and familiar solution for users who want to elevate a command without having to first open a new elevated console.
We are also excited to announce that we are open-sourcing this project here on GitHub! We’re working hard to add more information about the project in the GitHub repo and will be sharing more details about our plans in the coming months! If you’re looking for additional functionality that Sudo for Windows does not provide, check out Gerardo Grignoli’s gsudo which has a number of additional features and configuration options.
You can also check out the Microsoft Learn docs for more information here.
How to enable Sudo for Windows
To enable Sudo for Windows, navigate to the Settings > For Developers page in Windows Settings and toggle on the “Enable Sudo” option:
You can alternatively enable Sudo for Windows by running the following command in an elevated console session:
sudo config --enable <configuration_option>
How to configure Sudo for Windows
Sudo for Windows currently supports three different configuration options:
- In a new window (forceNewWindow)
- Input closed (disableInput)
- Inline (normal)
To change the configuration option, use the drop-down menu in the Settings > For Developers page in Windows Settings:
You can alternatively change the configuration option by running the following command in an elevated console session:
sudo config --enable <configuration_option>
Configuration Option 1: In a New Window
In this configuration, Sudo for Windows will open a new elevated console window and run the command in that window. This is the default configuration option when sudo is enabled. For example, if you run:
sudo netstat -ab
A new window will open and the command will be run in that window:
Configuration Option 2: Input Closed
In this configuration, Sudo for Windows will run the elevated process in the current window, but the new process will be spawned with its stdin closed. This means that the new process will not accept any user input, so this configuration will not work for processes that require further user input after elevation.
Configuration Option 3: Inline
This configuration is most similar to the behavior of sudo on other operating systems. In this configuration, Sudo for Windows will run the elevated process with its stdin, stdout, and stderr all connected to the current window. This means the new elevated process can take in input and route output to the current window.
How does it work?
When elevating a process from the command-line with sudo, a UAC dialog will appear asking the user to confirm the elevation:
Once the user confirms the elevation, the process will be elevated based on the configuration option selected by the user.
You can check out the optional parameters for the sudo command by running sudo -h in your console.
In a New Window
In this configuration, sudo.exe will launch a new elevated console window and run the command in that window. The new window will be launched with the same working directory as the current window. The new window will also be launched with the same environment variables as the current window. This configuration has a similar flow to the runas command.
Input Closed and Inline
In these configurations, sudo.exe will launch a new elevated process, an elevated sudo.exe process, and the original unelevated sudo.exe will establish an RPC connection with the new elevated process. In other words, information is passed from the unelevated sudo instance to the elevated one. Specifically, the console handles from the unelevated process are passed to the elevated process which allows the elevated process to read input from the unelevated process and write output to the unelevated process. However, when sudo is configured in the “Input Closed” configuration, the elevated process will essentially not be passed the console’s input handle, so it will not be able to read input from the user.
Here is a diagram of how the process hierarchy looks:
It is important when running sudo in the “Inline” or “Input Closed” configurations to be aware of the security implications. It is possible that a medium integrity process can drive the elevated process. This risk is mitigated in the “Input Closed” configuration because the elevated process will not be able to read input from the user.
Over the coming months we will be working on expanding documentation for Sudo for Windows and will be sharing more details about the security implications of running sudo in the “Inline” configuration.
What’s next?
Our team is working on open-sourcing Sudo for Windows and we’re excited to share more details about our plans in the coming months. In the meantime, we’d love to hear your feedback! Please share your feedback directly in the GitHub repository.
Light
Dark
29 comments
I love it but new window over inline by default feels like a really bad choice. It’s unfamiliar to users on other platforms, which this is copying. I suggest changing that.
New window is preferable (especially over inline) as a default for security reasons. If a user understands the implications of using inline or input closed then giving them the option to do so is reasonable I suppose, but making them the default is just unnecessary and asking for trouble.
I would have expected an explanation why the engineering effort to create sudo for Windows, when we already have runas for years.
Thanks for the feedback. Check out https://learn.microsoft.com/en-us/windows/sudo/#how-is-sudo-for-windows-different-from-the-existing-runas-command in the docs!
Instructions unclear, accidentally deleted /etc/sudoers from Windows.
+1!!!
Does this have logging capabilities yet?
Will this eventually have scriptable rules…
Ie… This command –> Do it this way for safety…
Other command (only this group of users) –> allowed to do this way for convenience…
Will there ever be a workaround to use a password, instead of the annoying UAC?
Will this eventually have sudo insults?
I may jest a touch on the last one, but Windows Tested by a Company, on a powerful machine; can be a great Linux User experience.
I never thought I would feel this way, but I just found out how to enable systemd recently, and windows is finally good if you pay enough.
Thanks for all the hard work Dev teams!
You wrote that “When elevating a process from the command-line with sudo, a UAC dialog will appear asking the user to confirm the elevation” and in the window it shows that the run programm is a Microsoft Program. How does this protect from things like “sudo cmd /c myrootkit.exe” (which could be the elevation asked for inside an evil installer)?
Realistically, I don’t think it does at this point. If you click Show more details on the consent dialogue, you’ll see the full command line, but I’m very skeptical that users will consistently do that, especially when the prompt is saying things like “Verified Publisher: Microsoft Corporation”. I don’t think the consent dialogue is really doing its job here and needs a bit more work before this leaves preview.
Actually, for the default New Window configuration, I’m a little curious why they’re not just using ShellExecute and letting the normal elevation process do its thing which would presumably solve the misleading consent dialogue (at least in that case). I imagine it’s because they want to pass on the working directory and environment variables… I’m not sure how I feel about that. The convenience aspect is obvious, I guess, but my understanding is that the AppInfo service specifically avoids doing that for good reasons. Hmm.EDIT:Nevermind, I started watching the video and it seems like they do actually ShellExecute (or something similar) for the New Window configuration. Apparently they still change the environment variables though? That is curious.
Linux much???
What was wrong with just the basic UAC interaction demanding that a user approve elevated privileges with a local admin password?
I fear that you have taken a step in the direction towards unnecessarily complicating such a simple concept as command line “sudo” with the perception that you have somehow made the life of admins and developers “easier” while still being secure.
At least, take the sensible route and eliminate the UAC interaction in favor of something like mandatory membership in a designated security group before allowing a user to just invoke “sudo” as a CLI command without ALL of the silly back and forth between different windows and the like.
If you want to be like Linux, then be like Linux.
And make sure you enable detailed logging of the the full command line and arguments when a user invokes your version of “sudo”.
We have that, it’s called the Administrators group. Auto-allowing someone to do something because they are a member of some group is a security hole and easily hacked. That’s the whole point of UAC. If you allow unrestrained access by users in certain groups then you have not yet been a victim of an inside hack. You are fortunate.
Honestly I think this entire tool is a useless security risk. If you cannot run an elevated terminal, or know how to do it using runas, then maybe you shouldn’t have that kind of access. Making it easier to run as admin makes it easier to hack your system. I would never install this tool and I would go so far as to say we would have a company block on any team member installing it.
Can you share your console setup?! 🙂 I love the colors and the basketball “prompt” !!! 🙂 how did you pull that off!?
Absolutely! I actually have covered the setup in various depths and forms so I’ll start there, but feel free to reach out if you have any issues or any more questions.
Make Windows Terminal Look AWESOME in Just 5 Minutes: https://www.youtube.com/watch?v=yxzYixOmPHg&t=140s
Video where I actually code up the NBA segment for Oh my Posh from scratch: https://www.youtube.com/watch?v=NR7i0SKFbtI&t=589s
Blog post about how to set up: https://joadoumie.github.io/jordi-rants/2023/10/24/oh-my-posh-nba-segment.html
GitHub Gist of my profile (.json file that describes the structure of the oh my posh segments): https://gist.github.com/joadoumie/5353b15418e98c7c678e0e6cbde1d6f7
Copying my comment on the YouTube video:
The Windows and *nix sudo commands are different enough that they should have different names. Copying the name didn’t work out so well when “curl” was made an alias for “Invoke-WebRequest”. I also don’t see many people complaining about e.g. ifconfig vs ipconfig.
If sudo on Windows supports the exact same same syntax, flags, options, etc as sudo on *nix, I could see the case for keeping the names the same since the user-facing functionality would be very similar. But even then, just the UAC prompt alone makes it different enough that I’d call it something else. My natural inclination is that two tools with the same name should do the same thing, and this is not true of sudo on Windows.
All that being said, I LOVE this idea of making something better than “runas”. Good job!
I hear you! We thought about some of the options you’re calling out here. A lot of customers voiced having the muscle memory of doing similar flows on various operating systems was more important to them and that’s where we landed. I totally understand your perspective and I do really appreciate the feedback. I’m always trying to learn from people like you so I can help to build things that will make your life better.
Muscle memory? Please rename cmd.exe into bash in one of the next Windows updates then. And I think that renaming notepad.exe into nano is also a good idea following your excellent logic.
And in the end just rename Windows into WinBSD.
While at it, can you (you as in Microsoft) rename “Run as Administrator” to something that reflects what it really does?
It’s a bad idea to name the new command “sudo”. Does it share code with the original sudo utility? If not then call it something else.
I can see only one possible application for sudo in Windows:
sudo rm -rf c:\windows
or even better from a liveDVD with any distro:
wipefs -a /dev/sdxY where windows is installed.
I am really curious to see how that works in an enterprise environment where no-one is in a administrator group and a network operators groups is used to elevate privileges to plus level but never above that.
Will be interesting.