Will Microsoft Bring the Linux 'Sudo' Command to Windows Server? (bleepingcomputer.com) 100
An anonymous reader shared this report from BleepingComputer
Microsoft released the first Windows Server 2025 Insider preview build last week. However, soon after, a newer version was leaked online. As first reported by Windows Latest, the leaked version contains some new in-development features, including new settings for a Windows 'sudo' command.
These settings are only available after enabling developer mode, and the sudo command does not currently work from the command line yet, showing it is early in development. However, the sudo settings provide some clues as to how the command will work, with the ability to run sudo applications 'In a new windows', 'With input disabled', and 'Inline'....
It is important to note that Microsoft commonly tests new features in preview builds that do not make it into the production builds.
Obligatory XKCD.
These settings are only available after enabling developer mode, and the sudo command does not currently work from the command line yet, showing it is early in development. However, the sudo settings provide some clues as to how the command will work, with the ability to run sudo applications 'In a new windows', 'With input disabled', and 'Inline'....
It is important to note that Microsoft commonly tests new features in preview builds that do not make it into the production builds.
Obligatory XKCD.
Re:SUDO should not even be in Linux (Score:5, Funny)
Come to the BSD world. We have "doas" instead.
Re: (Score:3)
Re: (Score:2, Flamebait)
Properly restricted "sudo" can be fine in a limited number of circumstances. Usually, it is not. It is also very easy to screw up a sudo configuration. And allowing regular users to sudo generally? That is just broken in anything but a diagnostics usb-stick linux or the like. You might as well do away with the root account altogether or work as root. There is not much difference with unrestricted sudo.
Re: (Score:2)
It's pretty tricky to use it as a security barrier, even when it works perfectly, because so many of the tools that you'd potentially want to use sudo to grant access to are not really designed to restrict the user: once you h
Re: (Score:2)
Through the years, the sudo utility suffered from several security holes built right into it. None of these ever impacted the su utility as far as I can tell.
Re: SUDO should not even be in Linux (Score:1)
Re:SUDO should not even be in Linux (Score:4, Informative)
>"Come to the BSD world. We have "doas" instead."
And is also available in Linux
https://www.makeuseof.com/how-... [makeuseof.com]
Or you can also use "runser"
https://www.man7.org/linux/man... [man7.org]
And setpriv
https://www.man7.org/linux/man... [man7.org]
Re:SUDO should not even be in Linux (Score:5, Interesting)
You do know Sudo was invented on BSD Unix back in 1980 according to the man pages.
Re: (Score:2)
Re: (Score:2)
Re: SUDO should not even be in Linux (Score:2)
What could possibly go wrong.
Nice (Score:5, Interesting)
Can't tell you how many times i launched cmd prompt non administratively then had to close and re-open as admin. Now i can just waste exactly as much time typing sudo! But seriously it does seem helpful for scripting maybe.
Re: (Score:2)
Oh, I'm sure you'll still have to run the command prompt in administrator mode in order to use sudo.
I hope they don't, it's not a great idea from a security perspective.
Re: Nice (Score:2)
Windows alrealy had a 'su' context where a privileged program/user like 'everyone' could call processes in the context of a more privileged user like 'system' without the actual user's input. A sudo command in there somewhere would be interesting....
Re: (Score:2)
I always just used the runas command in those situations.
Re: (Score:2)
Re: Nice (Score:2)
Pretty sure you can if you use bash. The !! feature comes from bash. As long as runas is a regular executable found in the path, then it should work fine.
Re: (Score:2)
Really? windows lets you see stdin from the process list?
I have used runas many times and it has never once recorded that password anywhere. It prompts for the password, I type it in and it is not echoed to the screen, and it's done. Just like su on unix. You *could* p
Re:Nice (Score:5, Informative)
There's a distinct difference here.
Opening a command prompt as admin means that the person doing so must be allowed to run every single program as administrator. Because that's the consequence of doing this. A privileged CMD (or PS) means that you can execute any command with the privileges of the admin account. That's probably not what you want, or what you need.
In a work environment, I may want to grant a particular user the ability to launch a particular program with administrative (or other) permissions, but no other programs. And I frankly don't even know if the runas command can be configured to provide this level of granularity.
Re: (Score:2)
Create a group with "execute" permissions applicable to one (or more) programs, then add or delete users from that group?
It's not that difficult.
Re: (Score:2)
That sounds a lot more complicated than a simple sudoers file.
Re: (Score:2)
Even if it did, it would have to be locked down to only allow specific applications.
Running notepad is too lenient, because File -> Save As allows opening a command prompt by typing "CMD" in the folder selection box at the top. The same applies to anything else that uses the stock Save As dialog window.
What's instead wanted is having custom software that makes admin-level changes based on input from
Re: (Score:2)
Re: (Score:2)
then had to close and re-open as admin. Now i can just waste exactly as much time typing sudo!
You either have lightning fast reflexes or are the world's slowest typer. Typing sudo is far faster than relaunching your entire terminal, to say nothing of the fact that often you'll find the context of the terminal has changed (e.g. you may need to renavigate to a directory).
But that's all beside the point. Everything you do in a terminal is executed with the permissions of that session. It's not a good practice to run an administrative session as it can lead to dangerous consequences that are often prote
Re: (Score:2)
How is typing up-arrow, Home, sudo, and space slower than closing the current window and re-opening powershell as admin? The latter even involves a trip through UAC. And then you have to retype the entire command as it's not in the history.
I would assume at a very basic level the sudo com
Re: (Score:2)
Wasn't this the purpose of UAC back in the Windows XP days?
Windows XP has no UAC. Unless you mean the evil corporation from DooM.
Re: (Score:2)
You are thinking of Windows Vista, not XP.
Re: RUNAS unavailable for comment (Score:1)
Re: (Score:1)
Re: (Score:2)
That seems like it still wouldn't work properly with Active Directory. There is no real "superuser" in AD. You can't impersonate a user without their credentials, and possibly some other security flags like delegation. A domain admin can force change a password, but that's irreversible.
obligatory OG quote (Score:5, Funny)
Re: (Score:2)
Beat me to it.
Re: (Score:2)
Indeed.
Re: (Score:2)
+100
Eventually, MS-Windows will be where Unix/Linux were a few decades ago. How exciting for them...
Re: (Score:3, Funny)
Yes, because *nix and variants are supreme, never been cracked/hacked. No security vulnerabilities here, no sir.
sudo is a pain in the arse, and a band-aid solution to giving users sufficient authority to do their jobs.
Re: (Score:2)
nope (Score:2)
C:\>sudo rm -rf *
'sudo' is not recognized as an internal or external command, operable program or batch file.
They should call it 'sume' (Score:4, Funny)
Because Microsoft really needs to get sued again :)
More details (Score:5, Funny)
The article didn't explain the actual syntax of the shell command:
Re: (Score:2)
Seems like the kind of thing that could easily be aliased in powershell with a function in the user profile named "sudo".
Re: (Score:2)
Um, you just made that up, didn't you? I'm 99% sure.
Re: (Score:2)
Well, Microsoft does make it hard to avoid Poe's law when you try to make fun of their design choices. No matter how outrageous you make it, it still looks plausible.
Windows... (Score:1)
Re: (Score:3)
True. But it's my understanding that the Windows administration model differs significantly from *NIXes. root on Linux (and other unixes) is a completely separate user. Admin on Windows is a set of privileges granted to one (or more) regular users. You don't have to switch to another user. You might get a nice warning popup to the effect that you are about to do something "dangerous". But there are a number of seemingly innocuous tasks that you can get a Windows user to perform that, already possessing admi
Re: (Score:2)
On Windows if an account doesn't have admin permissions, you have to select an account that does and enter its password when trying to do admin stuff. If your account does have admin permissions, it's just a UAC prompt. The prompt can either run an app as admin level, or authorize a particular action only.
Overall the Windows system is more fine gained than Linux, but also suffers from legacy issues, i.e. apps expecting to have access to certain things that are now privileged. These days it's mostly been res
Re: (Score:2)
The main problem on Windows is that the permission model really is a complex and badly thought out mess. Even finding out the real permissions of a file and fixing them can be next to impossible with their "whole path" model. I have had to copy files with Linux to fix their permissions, for example. Basically designed by some really inexperienced people with too many ideas. I have no doubt that this mess is one major reason why things are far too hard to secure on Windows.
Re: (Score:2)
That's basically what UAC does for users with admin privileges - early on in the login process, the session drops privileges considered sensitive, and the UAC interstitial is what allows a process to add them back on again without having to do a full login from scratch.
Maybe sudo will just be a command lin
Re: (Score:2)
>"Sudo is a very bad idea in general. It is the embodiment of mental laziness and lack of security awareness. If you need to do work as root, you log in as root and proceed very, very carefully from there."
I almost never use sudo, nor do I log in as root.
I simply su (or "su -", depending on the circumstances) then do what I need... as you said, very carefully. Ah, that is a rather long pun (su and then do what I need). Hmm.
Re: (Score:2)
Well, "su -" is basically a root login. It is just not one via console or external interface. When on the local machine, I do the same. Remotely, I do a full root login (via ssh) as still nobody has given me a single good reason why you should not log in as root. I have gotten a lot of bogus and bad reasons though and these I just ignore.
Re: Windows... (Score:2)
I do not enable root via ssh because that is always a target. I ssh via a user with low privileges and then su - to root.
Whenever I have seen root login allowed via ssh the logs are full of bots trying to crack their way in.
Re: Windows... (Score:5, Insightful)
Sudo is a very bad idea in general. It is the embodiment of mental laziness and lack of security awareness. If you need to do work as root, you log in as root and proceed very, very carefully from there.
WTF...You're being serious here aren't you? Please tell me this is a joke. If I'm understanding you correctly, you advocate:
1) Log in as the actual root account, meaning all users that have to do something as root on that system share just the one root account with no audit trail. AND the root account isn't configured to /sbin/nologin or/bin/false
2) Do everything as root until your main task is done, including running scripts and other tools that don't actually need root in between subtasks that actually do need root
3) Using sudo judiciously for each command is lazier than simply logging in as root only once to do everything
4) Everything above is the most secure way to do things
Is this what you're telling us? Because if so, you're about the last person I'd trust to secure anything. Here's somebody who actually gets it:
https://askubuntu.com/question... [askubuntu.com]
Re: (Score:2)
I am completely serious. I am also an IT security expert, teacher, auditor and consultant. Maybe you need to re-evaluate your stance.
1. Users should never do anything as root. Users may call suid mechanisms and these should come with auditing. sudo sabotages that approach unless configures very, very carefully. Which it usually is not.
1a. Obviously, if you need audit trails on the root account, you use a jump host for them. This a) separates the users and b) actually makes sure you get the full trail.
2. Hav
Re: Windows... (Score:3)
I am completely serious. I am also an IT security expert, teacher, auditor and consultant. Maybe you need to re-evaluate your stance.
/facepalm
1. Users should never do anything as root.
/double facepalm ...please...just...stop...
Srsly...Everything you've said is so incredibly bad that it's not even necessary to call bullshit on your claim of having anything to do with security at all. It's self-evident.
You're even worse than the guy in my signature. Sure, he's a bad coder, but to the best of my knowledge, at least he doesn't go around deliberately breaking a security model and then call his pile of shit more secure. That turd of a trophy is all yours.
Re: (Score:2)
Really? Revoking sudo access is a heck of lot easier than changing root passwords across a cluster of servers even though that still happens pretty regularly. Not to mention auditing that sudo and similar mechanisms offer. At one time I remember exploring Kerberos to grant root access because it was revokable like regular sudo was but also tickets could be forwarded from machine to machine which was quite convenient and had even better access audit logs than plain sudo. But for most things sudo was enough.
Re: (Score:2)
In practice, most sudo users directly edit /etc/sudoers. It destabilizes further configuration changes, and can lock admins out of sudo if accidentally mishandled.
Re: (Score:2)
Always a possibility. Also someone with a root password could change the root password too and lock others out of a machine.
Kerberos certainly was an interesting solution to the root password problem. And it would have worked well, but at that point in history, it wasn't well-integrated into LDAP in a way that made administering it simple. Now with things like FreeIPA that integrates Kerberos, that is the direction I would go, and use tools like ksu. Kerberized tools maintain an audit trail, even as you
Re: (Score:2)
Microsoft deliberately *broke* Kerberos integration in an embrace and extend process. The desires for annual licensing, rather than compatibility, also helped limit the Kerberos in Active Directory. FreeIPA is burdened by being a rebuild of Samba with a "big picture" corporate oriented design, and no control of the underlying codebase to ensure ongoing compatibility. And the sssd client is poor: The underdocumented, monolithic configuration file and the insistence on starting, working temporarily, then cras
Re: (Score:2)
You do hand out root passwords to people that should not have it? I guess I know where you went wrong.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Most people also don't rekey their homes after they buy them. Shit, most people have remote garage door openers with codes that are their address. That doesn't make it a good practice.
Re: (Score:2)
Hehehehe, indeed. That is why some environments have moved entirely to ssh-keys for log-in and that goes to a jump-host or has an SSO in the loop where you can allow/block all users individually. No direct log-ins (except the "break-glass" ones) allowed, even for root.
Re: Windows... (Score:2)
You make it sound like you're using an optional bastion server (wtf?) with some off the wall hack to add access controls that are only for root.
Which is needlessly convoluted and even makes your attack surface bigger. Why on earth would you do it that way instead of just using pam with ssh certificates?
Though I think it's more likely that the actual security team implemented it that way and you're the help desk guy struggling to describe how it works while trying to make it sound like you actually implement
Re: (Score:2)
Hahaha, no. But jump-hosts with personal accounts for root-access are a thing. Especially in a regulated environment, were full logs of what people did as root are required. On-machine audit-logs really stop working in that case.
Also, you find changing root passwords difficult across a cluster? I mean, just log-in with the old root password and change it. Or better, do away with it completely and just remove their cert form the ssh authorized keys. Sure, if they left something behind (almost all admins are
Re: (Score:2)
Too funny. I'm so glad you know where everyone else is going wrong!
Re: (Score:2)
Well, you know this is one of the things that gets my regulated audit customers a "red" finding (has to be fixed and soon and gets escalated to the regulator). IAM, and more so PAM, is a thing that many IT departments have no clue how to do right. In regulated environments, my experience is that IAM is usually ok, sometimes not, but PAM is often only ok after I talked it over with them and they have implemented my recommendations or did something actually well thought out by themselves after I explained the
Re: (Score:1)
Re: (Score:2)
In such a scenario, how do you provide the user with the ability to run a specific command with elevated privileges without allowing them to do the same with every other command?
Re: (Score:2)
Suid executables and wrappers with stored parameters or very careful parameter sanitization. Yes, I know you can try approximate that with sudo, but it is just too hard to get right and too often becomes a privilege-escalation vulnerability.
Re: (Score:2)
In my experience, suid executables are way more prone to such things. I'm doing pentests for a living, and whenever you encounter a suid file that's not set by the operating system by someone who knows what they're doing, it's usually a low-hanging-fruit finding.
Most admins are more apt tightening sudoers permissions than messing with permissions and parameters in suid files.
Re: (Score:2)
Well, I may be relying too much on my personal experience and approaches here. I find suid scripts and executables very easy to get right, because I have everything in view and all means at my disposal that I need and hence minimal privilege and careful input validation is easy to do. At the same time, I find sudo more than a bit opaque and it is exactly that one suid-binary that has too many permissions and too much flexibility and is obviously something an attacker will try out first.
Sure, with people mes
Re: (Score:2)
Well, not wanting to go into detail for obvious reasons, but we do have a setup here where a lot of machines share configurations, and messing with suid bits can often have very nasty side effects in such a configuration. You'd rather have machines where sudo-settings deal with local permissions in such a case.
Re: (Score:2)
Well, yes, especially if they are not exactly he same. At the very least, things get messy in that case and that is not good for security. Also depends on how restrictive you want to be. Obviously, you can combine both things, i.e. the executable or script not being suid and you call them via sudo instead.
But my guess would be that this is not the common set-up and most people have sudo configs that are too permissive, simply because the distro came that way and it makes things a lot easier. Linux/Unix is n
Re: (Score:2)
CIS to the rescue [cisecurity.org].
It is possible to harden a system sensibly. It has to be done, though, and you have to accept the limitations it will impose on your system. But it can be done, securely and sensibly.
Re: (Score:2)
Indeed.
I do like the CIS controls. I recommend them to my IT audit customers and when teaching IT Security Management. They are just so much better than all the other main catalogs. Even when you want an ISO certification, it is a good idea to actually use the CIS controls for most of the work and then translate that to ISO.
Re: Windows... (Score:1)
Except if you lock root. I find more secure to have 2FA users with sudo than a usable root. And with that setup you still have logs of who did what. And you work as a normal user most of the time.
gsudo (Score:3)
Are the sure it's "sudo"... (Score:2)
... or is it Sussudio [youtube.com]?
Sudo? Are they porting vocabulary from Linux too? (Score:2)
The terminology differs. Windows has the 'Administrator' user instead of the UNIX 'super user'.
Why call it sudo then? Call it 'ado'.
Re: Sudo? Are they porting vocabulary from Linux t (Score:2)
Linux has "root", so I'm not sure what you're getting at.
Obligatory nitpicking (Score:3)
the Linux 'Sudo' Command
sudo isn't a Linux command. Some Linux distributions provide it, that's all. Plus, it was invented outside of Linux.
For the curious, 'troff' is not a Linux command, either.
Re: (Score:3)
Re: (Score:3)
For Windows users? (Score:2)
Re: (Score:2)
Neither are C programmers, what's your point?
Re: (Score:2)
How to become a billionaire? (Score:1)