Support sudo <PowerShell cmdlet>

[joeyaiello]

Steps to reproduce

sudo Remove-Item foo.txt where foo.txt is owned by root

Expected behavior

foo.txt is deleted

Actual behavior

sudo: Remove-Item: command not found

[MaximoTrinidad]

Hum! Very interesting. But, I think the actual behavior is as expected. As in Windows we don't have a command like sudo.
But, you could use 'sudo powershell' and then do the remove foo.txt (which was created using 'sudo powershell') then it works when using Remove-Item. Of course, it won't work in a non-elevated permission.

I would only use 'sudo' on Linux commands ("sudo nautilus") from within PowerShell.

:)

[SteveL-MSFT]

Even on Windows, it would be good to have similar capability to run a cmdlet as another user or elevated and something that could relied on in portable scripts. May need an RFC for this.

[pcgeek86]

This functionality would be useful to work around #3506.

[pixelrebirth]

This is going to become a blocker for adapting Linux for me if this is not resolved. We are not allowed to sudo bash and similarly will not be able to do sudo powershell.

I agree with Maximo, we should leave sudo to bash and make a new cmdlet for doing elevation in powershell using sudo as scaffolding on expected functionality.

[SteveL-MSFT]

@dantraMSFT has been investigating this, Dan can you provide an update on some current thinking for this?

[dantraMSFT]

@pixelrebirth Can you provide more detail as to what you expect? Are you expecting simple execution with a wait, output redirection or pipeline redirection?
Some example usage would be useful as well.

[pixelrebirth]

@dantraMSFT For sake of the argument I am going to call the new sudo like cmdlet: Invoke-Elevated
This is how sudo works and would translate to Invoke-Elevated in a powershell way

$cred = Get-Credential
Invoke-Elevated -credential $cred -command {
        Get-ChildItem ./test | Remove-Item -force
} | Get-SomeCmdlet

In this example, everything in the scriptblock would be executed elevated and then piped to a NON elevated Get-SomeCmdlet
Cred can be a different user or yourself as an elevated user (permissions needs to be kept somewhere like sudoers file does aka a whitelist)

Logging should be enabled, by default for instances where Invoke-Elevated is executed:
User | Command | DateTime or similar format logging

Maybe some of this gets extended or changed later, but this is what would remove my blockers

[pixelrebirth]

It should also work like:

Get-ChildItem ./test | Invoke-Elevated -command {Remove-Item -force}
Where the credential is your current user and it just asks for the password...

Get-ChildItem is NON elevated, Remove-Item is elevated in this example

[pixelrebirth]

I was on the community call today asking about this, but my wife got hurt during the explanation of the challenges for it and I missed a lot of it. Can you please put notes here so I can relay them to my boss?

I will help however possible and put pressure wherever I need to.

[joeyaiello]

@pixelrebirth hope she's okay! We'll be putting up a recording of the call in the next day or two, so you can catch up if you like.

Basic summary is that @dantraMSFT is doing an initial investigation to figure out how to do this in a non-hacky way. Today, you can sudo powershell -c "invoke-foo" from another shell, but that's obviously not workable.

@dantraMSFT : as you work through your investigation, maybe post some status to make sure that everyone understands the tradeoffs with different approaches?

[pixelrebirth]

It may seem obvious, but maybe take a look at the sudo source code and see how they manage it-- maybe it requires some low level coding. I wish I had a deeper code understanding to help.

She is okay, she feel on her surgery hip. Thanks for the fast response on this. I am working on a little hack work around I will post here if I pull it off.

[iSazonov]

Can you elaborate that a bit more? I can remote to that machine and from any machine to any other machine in the network, but from none of them to localhost. And yes I read that page.

Most attacks target local elevation. So all configs is "secure by default". WMI, WinRM, IIS loopback and etc - all subsystems disable features which allows local elevations.
It is not so important for the discussion. Even if PowerShell remoting does not allow us to do sudo by default, we could implement it turned off by default or allow only for an interactive session.

You started talking about windows, for non windows systems we could use the unix socket approach to implement impersonation/elevation for powershell remoting there.

We should have the same UX for all platforms. Really there PSRP works over a transport - WinRM or SSH. MSFT said that they like SSH but I do not see any noticeable progress over the past two years. And it's unbelievable that they will want a third protocol in the near future - too much work (the need to maintain compatibility with old systems).

[agowa]

Most attacks target local elevation. So all configs is "secure by default". WMI, WinRM, IIS loopback and etc - all subsystems disable features which allows local elevations.
It is not so important for the discussion. Even if PowerShell remoting does not allow us to do sudo by default, we could implement it turned off by default or allow only for an interactive session.

I tried to enable that a while ago, and I was told repetitively by many others that this is restricted by the os internally and it is not possible in any way without an application hooking deep into windows internals. In fact many have pointed at the above referenced windows api restrictions and used that as argument for why powershell could never provide such capability. And someone even referenced an CVE where loopback elevation was intentionally removed. Therefore apologies going down that rabbit hole a bit deeper, but what do I need to configure for it to work? Is that even documented anywhere?

We should have the same UX for all platforms. Really there PSRP works over a transport - WinRM or SSH. MSFT said that they like SSH but I do not see any noticeable progress over the past two years. And it's unbelievable that they will want a third protocol in the near future - too much work (the need to maintain compatibility with old systems).

Well than we should push forward either of both solutions as both work on any platform.

• PSRP: SSHing to localhost works for elevation on Windows and Linux, therefore using the psrp subsystem we already have the correct permissions, so only the powershell layer has to be uniformed to allow passing objects. Right?
• Using unix sockets would also provide a similar functionality like powershell remoting, but as time of writing I assumed it is a hard limitation to do local elevation without any kind of additional service running as local system to perform token swapping...

Therefore as powershell remoting is already there (and also kinda works over ssh already) we should prioritize that solution I think.

[iSazonov]

And someone even referenced an CVE where loopback elevation was intentionally removed.

I cannot confirm. I guess the CVE could just disable loopback by default but not at all.
See also #3874 (comment)

[agowa]

@iSazonov: That does not work, it only provides the low privilege access token but not the elevated access token (e.g. Mandatory Label\High Mandatory Level). I do not get Administrative permissions out of a low privilege powershell even though TrustedHosts is set to * for me. The logon token is always of type interactive, even after Enter-PSSession.
I can in fact Enter-PSSession localhost -ScriptBlock {} but passing credentials causes "Access Denied"., nope it always throws "Access Denied" that other system had uac disabled.

But I now tried it also using SSH and that works as expected it provides the elevated token (Mandatory Label\High Mandatory Level) with logon type Network.

Therefore in PSCore we can rely upon psrp for elevation (even locally through Enter-PSSession -HostName localhost that also works with explicit credentials being passed.
Where Enter-PSSession -ComputerName localhost -Credential $foo does not (even if $foo.Username is the same as the current user)

[iSazonov]

@agowa338 I think we should not discuss bypassing security features of WinRM here (it is compliance sensetive area). I can only indicate (1) that regardless of a protocol, security should remain at the same level, which implies that SSH loopback should behave the same as for WinRM taking in account how Windows internals work, (2) PS sudo implementation should works over any transport.

[agowa]

@iSazonov: I did not ask for an exploit, but only for what needs to be configured to enable it. Also you seam to be the only one that figured out how to configure WinRM in order to allow loopback elevation.
I've tried to enable that for a very long time. All questions (on stackoverflow, reddit, github issues, ...) I come across end in "windows is wird", "don't know what windows does there", "It is not documented anywhere", "Windows does not provide that capability", "Use Linux instead", "Disable UAC", "You need to write a broker service that runs with system privileges". So please if you figured it out, share your knowledge.

I can only indicate (1) that regardless of a protocol, security should remain at the same level

What do you mean with that?

which implies that SSH loopback should behave the same as for WinRM taking in account how Windows internals work

Well SSH has a system service that acts as a broker in the background to do exactly that. It provides a Network access token...

(2) PS sudo implementation should works over any transport.

Well it does not over WinRM for exactly that reason. So if it is true what you said we need documentation for how to enable loopback WinRM.

[iSazonov]

if you figured it out, share your knowledge.

@agowa338 MSFT team asked me do not discuss security publicly and I follow the CoC. I support your desire to explore this topic deeply, but as part of this discussion, this is a headache for MSFT how to integrate this solution into Windows and keep security compliance.

[agowa]

Well that does not help anyone.

To summon it up:

• You say windows has sudo like capabilities within WinRM.
• It's neither documented that it exists nor how to enable/disable it.
• Disclosing how to use it would be a security risk.

Sorry, but that sounds like a backdoor and not a feature. It is unusable for anyone except you than.
Also security through obscurity has not worked in the past either...

So we're back at it's currently not implemented and we need a broker service than...

[iSazonov]

@agowa338 We have gathered enough information for MSFT team to conclude. If they find security issues, they will show us an acceptable alternative way.

[jborean93]

It was possible but was patched earlier this year https://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/ with the patch KB4480116 and any subsequent cumulative updates.. Before this update it was possible to elevate your privileges if you have the LocalAccountTokenFilterPolicy set to 1 which is what winrm quickconfig does (and is required for WinRM really).

There's a note there saying JEA endpoints are not affected so potentially you could create your own PSSessionConfiguration and connect to that but I haven't tested this to verify. Personally I think this patch is silly as this patch just stops the PowerShell client from connecting to localhost but you can easily bypass it if you know what you are doing. For example I can still go from limited to elevated without touching UAC by using SSH or another PSRemoting client like so

PS C:\Users\vagrant> whoami.exe /groups  # prove the current process is limited

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
======================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Group used for deny only

BUILTIN\Administrators                                        Alias            S-1-5-32-544 Group used for deny only

BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Performance Log Users                                 Alias            S-1-5-32-559 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\REMOTE INTERACTIVE LOGON                         Well-known group S-1-5-14     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\INTERACTIVE                                      Well-known group S-1-5-4      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
LOCAL                                                         Well-known group S-1-2-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\Medium Mandatory Level                        Label            S-1-16-8192

PS C:\Users\vagrant> ssh vagrant@localhost whoami.exe /groups  # prove that SSH is elevated
vagrant@localhost's password:

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
===================================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Mandatory group, Enabled by
default, Enabled group
BUILTIN\Administrators                                        Alias            S-1-5-32-544 Mandatory group, Enabled by
default, Enabled group, Group owner
BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NETWORK                                          Well-known group S-1-5-2      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\High Mandatory Level                          Label            S-1-16-12288

PS C:\Users\vagrant> python -c "from pypsrp.client import Client; c = Client('localhost', username='vagrant', password='
<password>', ssl=False); print(c.execute_ps('whoami.exe /groups')[0])"

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
===================================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Mandatory group, Enabled by
default, Enabled group
BUILTIN\Administrators                                        Alias            S-1-5-32-544 Mandatory group, Enabled by
default, Enabled group, Group owner
BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NETWORK                                          Well-known group S-1-5-2      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\High Mandatory Level                          Label            S-1-16-12288

We can see that using SSH we have an elevated token, we can also see that using a 3rd party library we can still use localhost PSRemoting that creates an elevated token and that the patch is not a total block of this functionality.

I don't see this as a security issue or crossing a security boundary as MS has repeatedly said that UAC is not a security boundary

• https://blogs.technet.microsoft.com/markrussinovich/2007/02/12/psexec-user-account-control-and-security-boundaries/
• https://blogs.msdn.microsoft.com/e7/2009/02/05/update-on-uac/

It might be close or act similar to one but it is not foolproof. One of those ways of bypassing UAC is the known and documented LocalAccountTokenFilterPolicy registry property. The explicit purpose of this property to ensure that network logons are always elevated and not the filtered token and it explicitly says that not having this enabled prevents "loopback" attacks

To better protect those users who are members of the local Administrators group, we implement UAC restrictions on the network. This mechanism helps prevent against "loopback" attacks. This mechanism also helps prevent local malicious software from running remotely with administrative rights.

Ultimately what that means is there is no really official way on Windows to elevate your privileges from limited to an admin in a non-interactive fashion. It's quite simple to use Start-Process ... -Verb Runas but that requires an interactive logon to display the UAC prompt. Having a sudo-like mechanism would help alleviate this problem but to do it properly would require work in Windows itself and not be PowerShell specific. There are "workarounds" but I wouldn't call them official and are just a known byproduct of enabling WinRM.

PowerShell

Windows Security change affecting PowerShell | PowerShell

Windows Security change affecting PowerShell January 9, 2019 The recent (1/8/2019) Windows security patch CVE-2019-0543, has introduced a breaking change for a PowerShell remoting scenario. It is a narrowly scoped scenario that should have low impact for most users. The breaking change only affects local loopback remoting,

Mark's Blog

PsExec, User Account Control and Security Boundaries

I introduced the -l switch to PsExec about a year and a half ago as an easy way to execute processes with standard-user rights from an administrative account on Windows XP. In Running as Limited User – The Easy Way I described how PsExec uses the CreateRestrictedToken API to create a security context that’s a...

Engineering Windows 7

Update on UAC

Hi, Jon DeVaan here to talk to you about the recent UAC feedback we’ve been receiving. Most of our work finishing Windows 7 is focused on responding to feedback. The UAC feedback is interesting on a few dimensions of engineering decision making process. I thought that exploring those dimensions would make for an interesting e7...

[ghost]

@iSazonov None of these suggestions will accomplish a user-interactive command elevation from within the same console session, especially in an environment that lacks UAC. It appears that you can speak on behalf of Microsoft in these matters, so would you clarify whether they are simply not interested in in introducing such a feature as I have described it?

If that is the case, as I have interpreted from the above posts, it seems prudent to close this thread, as the rest of us users will have to look elsewhere for solutions such as @parkovski's TokenServer idea.

[iSazonov]

It appears that you can speak on behalf of Microsoft in these matters

I am a community maintainer of the project, not MSFT member and I can not speak on behalf of Microsoft.

would you clarify whether they are simply not interested in in introducing such a feature as I have described it?

All proposals have value; none of them are rejected. The discussion is just for collecting all possible proposals.

Currently I am trying to summarize all proposals so that we can move forward and not stagnate.

That I see.
Main scenario is adoption Unix users on Windows.

• Historically Unix users works in one console and sudo natively helps them to do a work with elevated rights in the same console
• Historically Windows users open new window with elevated rights console if needed. This works well many years because it’s convenient in a multi-windows environment. (Windows users could benefit from pssudo too taking in account Windows Core and Nano)

So expectations are:

• pssudo works only in interactive sessions
• pssudo does not open new console (UAC window is acceptable on Windows, we don't want break Windows security and spirit)
• pssudo timely cache credentals
• pssudo does not cache a session state for security
• the same UX (as possible) is on all platforms
• pssudo runs native commands
• pssudo runs PowerShell script blocks/files

Implementation details:

• PowerShell remoting is most power and functional solution. It is already implemented and works. Others would have to emulate this functionality too to excecute PowerShell script blocks in per user/per session/per runspace/ per scope state.
• Preferred transport is WinRM because all Windows infrastructure based on it. Some investment is required in WinRM, although MSFT does not want this because it is based on SOAP.
• SSH transport could be. This is still not the standard for Windows. Requires a large investment for implementation and maintenance. And there is a problem supporting older systems.
• Other transports like Unix sockets. Requires a large investments not only in infrastructure but in PowerShell too.

@mklement0 I wonder that I do here that you do usually great :-) You rob me of being an opponent :-)

[minecraftchest1]

Why not write an windows binary that requires privileges that starts a powershell instance with whatever commands passed to it. It would have to be a console mode app to work properly. Then for linux, we write a script that requires permissions that starts a powershell instance with the commands provided. If this works in practice like it does in theory, powershell will be launched with elevated permissions, runs the commands and exits.

[agowa]

Why not write an windows binary that requires privileges that starts a powershell instance with whatever commands passed to it. It would have to be a console mode app to work properly.

Cause the windows API prevents that and the console app would open in a new window. We already talked about possible workarounds.

[SteveL-MSFT]

One thing to keep in mind is that no matter how this gets implemented, there is always a process hop to and from an elevated process. This means that you'll always have deserialized objects in the pipeline and those limitations will apply. In many cases, this won't be an issue, but if a cmdlet expects a live .NET object, then it won't work.

To support JEA with SSH, we would eventually need a generalized daemon/service that replaces the need for WinRM as that service anyways. At that time, we would evaluate using that to elevate a part of the pipeline.

[majkinetor]

FYI: https://github.com/gerardog/gsudo

GitHub

gerardog/gsudo

A Sudo for Windows - run elevated without spanning a new Console Host Window - gerardog/gsudo

[Witchilich]

FYI: https://github.com/gerardog/gsudo

GitHub**gerardog/gsudo**A Sudo for Windows - run elevated without spanning a new Console Host Window - gerardog/gsudo

Even better
http://blog.lukesampson.com/sudo-for-windows

GitHub

gerardog/gsudo

A Sudo for Windows - run elevated without spanning a new Console Host Window - gerardog/gsudo

Luke Sampson - Sudo for Windows

Sudo for Windows

[majkinetor]

Even better

No.

Gsudo doesnt prompt for password each time and is noticebly faster to install and use.

[majkinetor]

It looks to me that this issue should be accepted (which means some more time and organization should be given to it) judging from the interest not only from this ticket. Its not correct not to officially recognize it as a work task as currently perceived technical difficulties are not going to be solved without active involvement.

I am using gsudo for a few months now and I can't imagine going back to traditional Windows UAC all the time horror.

[SteveL-MSFT]

@majkinetor this issue got spun off in #11343 to further discussion on the design

[agowa]

Is there an update for this feature request? The last referenced Ticket #11343 was already marked as done a while ago.

[bergmeister]

With Windows supporting sudo now (in Insiders) as first class citizen, this will allow at least wrap-around functionality: https://devblogs.microsoft.com/commandline/introducing-sudo-for-windows/

Windows Command Line

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.

[agowa]

Only client versions of windows. What is with servers?

[charltonstanley]

This issue goes back 7 years, so I may have missed somebody sharing this already, but in case it hasn't, here it is.

It seems that sudo -s will read the $SHELL environment variable to determine what shell to use to execute the command. I changed it to point to pwsh and that seems to work for my current need of moving a file.

#!/usr/bin/env pwsh

$Env:SHELL = '/opt/microsoft/powershell/7/pwsh'
$source = /tmp/file.csv
$dst = /home/user/tmp/file.csv
sudo -s Move-Item -Path $source -Destination $dst -Force

However, if I append -Confirm:$false to the Move-Item cmdlet, I get the following error:

Move-Item: A parameter cannot be found that matches parameter name 'Confirm\'.

So this kinda works for using sudo against some simple cmdlets on Linux, but for more complex commands you will definitely get unexpected results. YMMW. Use with caution.