Sudo/command line only elevation?

[parkovski]

I'm not sure this is the right place to ask about this, but I can't think of where the right place would be, so I'm just going to list my thoughts on this.

• As Windows command line functionality improves to the point that the system can be used remote/headless, this is becoming more of a necessity than an annoyance. Actually, this really comes down to having an official SSH client: SSH connections have to open as Admin, potential security hole.
• This is not some black magic thing or something that needs a UAC redesign or kernel work. I've experimented a little, and you can create a local service running as the system account which will give you elevated processes from the command line. I didn't pursue this any further though, because I don't have the time to commit to securing and testing the service, but I at least know it's doable.
• Even if I did want to publish a fully-featured sudo service, many organizations are not going to trust a third-party utility that is that big of a potential security hole, and it's unlikely the official SSH distribution would come configured for it, so now we're back at point one again.
• There is auto-elevation built into UAC, but only for the Windows publisher. So if this was a system utility, it's not even necessary to run it as a separate service.
• I think for the vast majority of users, this is entirely unnecessary, and I'd be fine with something that's enabled as a part of dev mode or when installing SSH. Those two cases do need it though.
• With WSL now we have a weird [restricted token, elevated token] x [regular account, root] scenario going on, where you have to be in the right kind of command prompt to get the correct privileges. If we had Windows sudo, I don't think it'd be too hard to unify it with the WSL sudo command.

Anyways, these are just my thoughts that I wanted to get out there. Happy to hear about any plans/concerns/a better place to have this discussion.

[parkovski]

Yeah, through SSH you technically can do anything you could do through UAC approval but you're not in an interactive session, so while you have permissions to do this, you can't just type "ssh someapp.exe" and have the GUI pop up, you'd have to make a shim that switches into the interactive session first.

Seems like SSH is not a security hole in itself, but at least auto-login loopback SSH is, whereas on Linux it isn't.

[agowa]

Could we utilize the COM elevation Moniker for this?

Alternatively, the security assessments for partially elevating an application clearly already exist over there. Maybe someone within Microsoft could also leverage this to create a similar native API? It would also help in many other cases where only specific actions require elevation. So instead of starting elevated and dropping privileges, an application could start as Invoker and only request elevation for specific features (Although I could have sworn that such an API for "on-demand elevation" already exists, I couldn't find any documentation regarding it right now).

And as a horrible workaround: We could use the com elevation moniker to run code that:

1. Further elevate to system by impersonating e.g. lsass (as we run as admin we can clone the primary token)
2. Now that we've access to SeTcbPrivilege privilege we could perform a token swap on the calling thread (not the whole process)

Edit: We could also use the COM elevation Moniker to just obtain a valid impersonation token. Starting the elevated com object would invoke the UAC for us, so just returning the elevated token would also be an option as we basically run whatever the non-elevated process tells us to anyway. Pseudocode:

Type comObjectType = Type.GetTypeFromCLSID(comObjectCLSID);
dynamic comObject = Activator.CreateInstance (comObjectType);
// either:
safeElevatedAccessTokenHandle = comObject.GetElevatedAccessTokenHandle()
WindowsIdentity.RunImpersonated(
  safeElevatedAccessTokenHandle,
  // User action
  () =>
  {
    Console.WriteLine("During impersonation: " + (new WindowsPrincipal(WindowsIdentity.GetCurrent())).IsInRole(WindowsBuiltInRole.Administrator));  
  }  
);
// or:
comObject.RunImpersonated(
  // Com object wraps call to WindowsIdentity.RunImpersonated and doesn't just leak the elevated token.
  // User action
  () =>
  {
    Console.WriteLine("During impersonation: " + (new WindowsPrincipal(WindowsIdentity.GetCurrent())).IsInRole(WindowsBuiltInRole.Administrator));  
  }  
);

[ghost]

@agowa338

"Per-command On-Demand Elevation With UAC GUI" already exist. two quick example --

1. windows date and time syncing.
2. third party apps - like Composer.exe the php package manager itself. running composer self-update on a medium IL command line shell invokes that "Per-command On-Demand Elevation With UAC" and doesn't open a new window.

---

The ask here is "GUI Less -- Per-command On-Demand Elevation" as the current form of UAC requires GUI.

so that, one could type sudo ssh someapp.exe inside a medium IL command line shell only using password and have that someapp.exe running with High IL.

Current SSH Loopback achieves that but it needs to implement --

1. Sudoers type of file/reg entries so that not every user can elevate every single commands/exe(s).
2. "UAC Secure Desktop" like command line-ish mechanism so that the password can't be spied on while typing.

[ghost]

@Sylveon's solution seems the cleanest one. https://github.com/microsoft/terminal/issues/1032#issuecomment-850556267

What it is : Modifying the OS's UIPI. Benefit : Removes injection issues, Allows mixed elevation under one HWND. Also Doesn't break existing apps by pulling App Manifest. (much like longPathAware.)

[ChGen]

How about having "Drop elevation" profile option (in case Windows Terminal runs as admin)? Does it make security hole too?

[agowa]

@ChGen That's just bad usability and bad security practice. It's against the concept of least privilege.

[ChGen]

@agowa338 , thank you for clarification.

[Viqsi]

I have, in the meantime, been making use of gsudo (https://github.com/gerardog/gsudo), and it covers all of my use cases. I'm not sure how it'd work in remote connection cases so this is probably still worthwhile, but it's been helpful enough for me that I'm surprised it hasn't been mentioned here previously.

[MouriNaruto]

I have implemented a lightweight POSIX-style Sudo implementation for Windows.

It makes user possible to use elevated console apps in non-elevated consoles.

For safety, the implementation uses the UAC for elevation and don't support credential cache. It also don't use homemade Windows service and any IPC infrastructures.

Introduction: https://github.com/M2Team/NanaRun/blob/0b6d760e18594d427658bbf9b88ce6b351f01fbd/ReadMe.md#minsudo Implementation: https://github.com/M2Team/NanaRun/blob/916efdf31eb941ef605878fe75cf63f2937bd0e7/MinSudo/MinSudo.cpp

Maybe the implementation can help you.

Kenji Mouri

[zadjii-msft]

Once again, I have to officially state that anything that's sudo-like is a security hole on Windows. Period. Use at your own risk. Any malicious application can send keystrokes to any unelevated window. Running anything like sudo in a non-admin window creates an opportunity for malicious.exe to run commands in your terminal with elevated privileges, just by calling SendMessage.

If we ever did ship something like sudo inbox, it would only be due to us figuring out a way to prevent that.

[agowa]

@zadjii-msft not necessarily. There are ways to have a security boundary within a single windows desktop. We could use AppContainer for that. https://docs.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation

Process Isolation Sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes. This prevents a properly contained application from corrupting other processes in the event of an exception.

Window Isolation Isolating the application from other windows, the AppContainer environment prevents the application from affecting other application interfaces.

Or as already mentioned using the OS's UIPI https://github.com/microsoft/terminal/issues/146#issuecomment-1013730679 @zadjii-msft Did you have time to push this idea any further internally at Microsoft or maybe to make an internal proof of concept?

[juliushardt]

Any malicious application can send keystrokes to any unelevated window.

@zadjii-msft It is also possible for malicious applications to inject arbitrary keystrokes into any elevated window. For example, a malicious application malicious.exe running at medium IL can use the undocumented ITipInvocation.Toggle() method to programmatically show the Touch Keyboard, whose HWND is hosted by TextInputHost.exe. Since TextInputHost.exe is running at low IL, malicious.exe can send input messages (mouse clicks) to TextInputHost.exe in order to "press" virtual keys. These keystrokes are then forwarded to the currently focused window, even if it is elevated (and running at high IL). This way, any medium-IL process can inject keyboard input into any window running at high IL.

If I understand the official documentation correctly, UIPI and Same-desktop Elevation are not a security boundary and, hence, the behaviour described above is not considered a security vulnerability. Interestingly though, the second on-screen keyboard in Windows, osk.exe, mitigates such input injection by running at an IL slightly above Medium (S-1-16-8208), which prevents medium-IL processes (S-1-16-8192) from sending input to this virtual keyboard.

The situation for mixed elevation in Windows Terminal or sudo for Windows seems to be very similar to that of the on-screen keyboard(s), maybe you could ask the respective team how they accepted/mitigated/solved it?

---

@zadjii-msft not necessarily. There are ways to have a security boundary within a single windows desktop. We could use AppContainer for that. https://docs.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation

Process Isolation Sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes. This prevents a properly contained application from corrupting other processes in the event of an exception.

@agowa338 I think the documentation is a bit unclear in this paragraph. Applications that run inside of an AppContainer can still be sent input messages by medium-IL processes. You can run the following experiment to test this with Windows PowerShell on Windows 11:

# Adapted from https://devblogs.microsoft.com/scripting/provide-input-to-applications-with-powershell/
Add-Type -AssemblyName Microsoft.VisualBasic
Add-Type -AssemblyName System.Windows.Forms
calc.exe
Start-Sleep -Seconds 2
[Microsoft.VisualBasic.Interaction]::AppActivate("Calculator")
[System.Windows.Forms.SendKeys]::SendWait("1{ADD}2=")

Even though CalculatorApp.exe runs inside of an AppContainer, it accepts input messages from powershell.exe, which runs at medium IL (and not inside of an AppContainer).

[agowa]

Just for completeness and because it is kinda related. https://github.com/Kudaes/Elevator

Elevator allows to bypass the UAC and spawn an elevated process with full administrator privileges

[JensGJ]

Once again, I have to officially state that anything that's sudo-like is a security hole on Windows. Period. Use at your own risk.

@zadjii-msft thanks for the warning - I understand that you do not want to allow mixed elevation due to this concern. What I don't understand is why it still works in Windows 10 (Windows Terminal 1.15.2874.0) but fails in Windows 11 (WT 1.15.2875.0). Under Windows 10 I can use gsudo to elevate a tab and still have non-elevated tabs in the same terminal. In Windows 11 this doesn't work. On the other hand the Ctrl-Click option to open an elevated profile only works in the Windows 11 version although the hover text showing the 3 keyboard options is still displayed.

[JensGJ]

The problem mentioned in my previous comment seem to be caused by a third party program - Admin by request - and not by Windows 11 directly.

[mmseng]

I've created issue #4217 to track the runas ask. We'll discuss with a bunch of teams internally - UWP runtime team, security, etc. and see what we can come up with. We'll update #4217 once we have some info to share.

It's pretty frustrating that the remaining canonical issue has been locked for discussion and ignored for over 2 years as a draconian punishment applied to everyone just because one user couldn't keep his tongue in check.

[DHowett]

It's pretty frustrating that the remaining canonical issue has been locked for discussion

Did you have something material to add? I would be glad to unlock it for further discussion. However: it definitely feels like we covered all possible opinions over there. :smile:

[mmseng]

I don't personally have the knowledge to contribute anything to the discussion, other than my desire to see the feature implemented. In fact I'm barely able to understand why this has been considered a lost cause. I'd have to read through it yet again but what I've taken away from it over the years is that Terminal has effectively considered the issue "wontfix" due to the design choice of chaining itself to the MS store installation mechanics.

Maybe I'm off base, but the point is, it wouldn't matter if I or anyone else did have something to contribute because there's no way to do so, aside from spinning up new issues or spilling over into others as I've regrettably done here.

If the issue is in fact dead then perhaps it should be closed. Either way, if there's not going to be any further discussion allowed, at the very least it would be appreciated to see a summary of the decision and reasoning in the final post, so that it's clear to everyone where the issue stands. To be clear I'm not necessarily saying we're owed this, or that shutting down the toxicity wasn't warranted.

[ChGen]

Yes, given that OS Windows since Windows 7 by default doesn't use strict UAC prompt policy, it's really strange that so much security concerns around Terminal being user-friendly with elevated admin. tabs (and by user, here's mostly advanced users, not average Windows user). I'm thinking on making some custom profiles with gsudo like apps... I would understand if this feature will be disabled by default, but for IT-specialists it'll be very convenient feature.

[mominshaikhdevs]

I have implemented a lightweight POSIX-style Sudo implementation for Windows.

It makes user possible to use elevated console apps in non-elevated consoles.

For safety, the implementation uses the UAC for elevation and don't support credential cache. It also don't use homemade Windows service and any IPC infrastructures.

Introduction: https://github.com/M2Team/NanaRun/blob/0b6d760e18594d427658bbf9b88ce6b351f01fbd/ReadMe.md#minsudo Implementation: https://github.com/M2Team/NanaRun/blob/916efdf31eb941ef605878fe75cf63f2937bd0e7/MinSudo/MinSudo.cpp

Maybe the implementation can help you.

Kenji Mouri

the moment anything uses UAC (which requires GUI in it's current form), it can't be used in command line only mode. thus we are back to square one.

the only ways that've been proposed so far to implement "a true command line only elevation mechanism"/sudo are :

1. change the UAC implementation itself in the OS, so that it supports command line only elevation without requiring GUI, in a secure manner.
2. using the author @parkovski's Windows Service mechanism and extending on that. https://github.com/microsoft/terminal/issues/146#issue-310659300.
3. @sylveon's modifying the OS's UIPI. https://github.com/microsoft/terminal/issues/146#issuecomment-1013730679.
4. a combination of the above three.

regardless of whatever paths the Windows team comes up with; End of the day, It's a must have feature for Devs.

[MouriNaruto]

@mominshaikhdevs

I don't think any elevation implementations that need to enter the password in the console meet the security requirement.

POSIX's sudo implementation can be easily bypassed automatically via pipe without any explicit notice to users if some malicious implementations know the password. I don't think it can meet the security goal for the Windows team.

I think the password authentication must be finished on a separate desktop from a separate session. We need to recall the reason that Microsoft introduced the secure desktop to show the UAC window for receiving the user credentials. (There are some historic lessons. Many malicious implementations are really good at emulating the user inputs.)

Kenji Mouri

[ChGen]

Actually I don't mind secure prompts in separate desktop session in UAC-style. I do mind, that I can't continue my work in the same window or at least in the near tab. This feature is missing for me as advanced user/IT specialist. But on the same time, Windows by default allows elevations without prompts for "safe" apps for whole public, including all not so experienced users...

[mominshaikhdevs]

@MouriNaruto

Yes, that's why I said "in a secure manner". It was already mentioned by somebody at https://github.com/microsoft/terminal/issues/146#issuecomment-1013449241

It requires that the Windows team implements "UAC's Secure Desktop" like feature but for a completely command lineish way/without any GUI prompt.

[MouriNaruto]

@mominshaikhdevs

It requires that the Windows team implements "UAC's Secure Desktop" like feature but for a completely command lineish way/without any GUI prompt.

In my opinion, no way to achieve that. Even the terminal can do that, but other 3rd-party apps that utilize the console pipe can't.

Unless we input the random credential token with a short time (for example 5 minutes at maximum) expiration instead of the password in the console, and get that token in the secure desktop.

Kenji Mouri

[MouriNaruto]

I think Windows can introduce something like two-factor authentication which using the time-based one-time password (TOTP; specified in RFC 6238) and HMAC-based one-time password (HOTP; specified in RFC 4226).

It may prevent some malicious implementations from emulating the user inputs easily and users can use Microsoft Authenticator on their mobiles to know the one-time password.

Kenji Mouri

[mominshaikhdevs]

actually anything is possible, if you think it hard enough and own/have access to the Windows Security source code.

Brand New APIs from the Windows team is required.

[MouriNaruto]

actually anything is possible, if you think it hard enough and own/have access to the Windows Security source code.

Brand New APIs from the Windows team is required.

It's not possible even have the Windows source code due to the design of pipe and console, and they need to keep the compatibility.

Kenji Mouri

[MouriNaruto]

If the thing is possible, they already implement it before, lol.

Kenji Mouri

[DHowett]

Hey there! Since there are so many people subscribed to this thread (and I'm sorry to be notifying them again) I'm going to lock it for now. If you want to talk about the potential implementation details for a "sudo for Windows"-like project, feel free to head on over to the Discussions section.

That way, we can keep this issue open for people who have subscribed for status updates. :smile:

[zadjii-msft]

Closing as we're shipping Sudo for Windows in Windows 11 Insider Preview Build 26052

For more discussion, you'll probably want to head to https://github.com/microsoft/sudo

[agowa]

@zadjii-msft Just one thing, can you say anything about the note in that announcement? What's the long term plan for server? To just have people diy patch it in? As an optional feature? With the next version bump?

That's probably the only thing that is still relevant for this ticket here.

NOTE: The setting for enabling Sudo may incorrectly be showing on Windows Server Insider Preview builds – this feature will not be available on Windows Server and the setting will be disabled in a future Server Insider Preview build.

[zadjii-msft]

@agowa I filed https://github.com/microsoft/sudo/issues/50 to track sudo on Server - I'd go engage on that thread if you have anything we can use as business justification ☺️