Does it have a policy editor comparable to the /etc/sudoers file? Sudo is interesting not because it just allows to assume admin privileges for a moment; it allows to give access in a finely-grained manner, and not exclusively admin access.
Just scrolling through the documentation [1] gives some idea. Examples in the end may surprise the reader with the variety of capabilities.
This sudo for Windows doesn't either because it's not sudo. Looking at the docs, it's not even remotely compatible either. The choice of name here is unfortunate.
Nitpick: it’s not “Sudo for Linux”, it’s just “sudo” and runs on a wide variety of operating systems aside from Linux. It actually predates Linux by around a decade.
I have noticed that runas is mentioned as an already existing sudo alternative, but as far as I know, runas asks you for the administrator's password. sudo asks the own user password. This is how you give a non administrator user the right to use some application/tool without revealing the admin's password.
You're right, but on my work environment I have two accounts - "me" and "me with elevated permissions". (I don't say "admin" because there's still a bunch of stuff I can't do, like run netsh). I assumed that was the normal pattern in Windows-land?
It is something of the normal pattern, it always seems like companies love it. It always seems like UAC with extra steps to me. It's not that much more secure than taking UAC as-is and dialing up the security settings on UAC prompts to require a password every time. It's often amusing to me that everywhere I've seen require "secondary accounts" for admin permissions has dialed down the overall security settings of UAC below the defaults.
Hacker accesses some legacy application that verifies the user's credentials against LDAP. Maybe it's payroll or something. Hacker logs passwords until someone who happens to be a org-wide local admin (or worse yet DA) wants their paystub. Hacker now has admin privileges.
(Also, if UAC settings are turned down, that might mean the UAC prompt isn't on the secure desktop, and any malware can thus trivially elevate itself if your everyday account is an admin... etc.)
Right, I don't think runas has a "sudo-mode" in terms of "let the user elevate their own permissions for specific tools even if they don't have an elevated account to elevate to", but runas is so low level and has so many weird combinations of arguments that maybe there is a buried similar way to that, I can't say for sure.
But the base "sudo" case where you have an account that supports UAC elevation (you are your own administrator) runas definitely supports as the CLI way to invoke UAC prompts for your own account, not just other administrator accounts. (Using the /trustlevel flag accordingly, as I recall.)
My question is more why they couldn't add this functionality into runas, rather than making a new tool that doesn't even do what its name says it does :)
It only explains what is different between sudo and runas. It doesn't really explain why they couldn't just improve runas and add those missing features instead of creating a new command. As it stands now you seem to need both sudo and runas to cover all reasonable use cases.
Backwards compatibility and changing the security dynamic of existing scripts. I'm sure it is probably possible to achieve using runas, but my guess is that it would greatly delay adding this functionality, as they would have to cover all concerns for which runas is used.
I really hope that sudo is going to allow one to capture the output of the thing running in sudo and handle errors better. I recently wrote an installer script in PowerShell and had to go through severe contortions to support privilege elevations for only a minimal part of the script. I needed to use start with runas to relaunch the same script with different options to continue the installation process and there's not much in the way of proper error handling either.
