Megathread: sudo, runas, mixed elevation of tabs, etc.

Summary of the new feature/enhancement

Current situation:

Suppose you are working on something in Powershell, CMD
You went into some folder
You built some history
You find out that you need administrator rights for some command

Currently most console apps (Powershell, CMD) need to start a new session for getting administrator access. This results in a less optimal workflow, because then you lose

your current working folder (you need to cd into it again)
your command history (the administrator session has its own history)

Proposed technical implementation details (optional)

A bit like sudo, started with a button:

Console sessions in terminal start with default permissions
Terminal has button with padlock icon / text "upgrade to administrator" in one of the corners
When you click the button, the current session is upgraded to a session with admin permissions or downgraded again to normal permissions
Session command history and location (working directory) is kept

Hans Bakker (@hansmbakker)

Hans Bakker (@hansmbakker) Windows Terminal (or any terminal for that matter) doesn't - and cannot - know anything about sessions, command history, or locations. It's just a (virtual) screen and a (virtual) keyboard that connects to whatever client (cmd, powershell, bash) the user wants to use. The responsibility for managing that information lies with the clients (applications) themselves. I understand what you're asking, and sympathize though. Using sudo in linux/osx makes life a bit easier at the command line, but unfortunately this isn't the way the Windows operating system is structured. Admin (elevated) processes and regular or restricted processes cannot communicate with each other. If you want something running as administrator, a new process is required.

Thanks for your feedback, but I'm going to close this as it's not feasible in the manner you would like.

Couldn't each tab run in it's own isolated process - with some being elevated, and others not - but in the same Window?

Martin Anderson (@mdtauk)

Martin Anderson (@mdtauk) In theory, yes. But (1) this isn't what the op is asking, and (2) I'm not certain if ConPTY is baked enough to allow this yet. At a minimum, I'd imagine the main terminal process would need to be elevated, or at least some kind of proxy process would need to be, but that means we'd then have to create a means of communication between the terminal, the proxy (which is a conpty server) and the elevated app (conpty client.) Things get hairy fast after that.

Oisin Grehan (@oising)

Oisin Grehan (@oising) Thanks for the reply. I think this suggestion has cropped up previously, and was wondering of the feasibility.

Its not as elegant as typing sudo or even elevate. But adding a profile for an elevated prompt which when clicked/tapped - brings up the UAC dialog, and then creates the elevated tab within the window - could be useful.

It's a pity that it is unfeasible, but thank you for your explanation.

elevated tab within the window

Hosting a connection to an elevated process in a window owned by a medium-integrity (that is: not elevated) process is dangerous because any other medium-integrity process could possibly inject input into it or scrape output from it. That’s the sole reason we’ve been given by the windows security team to not endeavour to do this.

Thanks for being transparent about it.

On the technical side, I’m wondering why sudo works while what I asked for can cause risks?

Thanks for being transparent about it.

On the technical side, I’m wondering why sudo works while what I asked for can cause risks?

Sudo is a Linux concept, and the way User and Admin concepts are handled between Linux and Windows are very different, and I guess that is what makes it not possible.

Hosting a connection to an elevated process in a window owned by a medium-integrity (that is: not elevated) process is dangerous because any other medium-integrity process could possibly inject input into it or scrape output from it.

Anytime someone uses sudo inside a terminal running on their normal Windows account, that scenario happens. It is extremely common. Linux users/admins do it all the time. My web browser also has access to mega-tons of sensitive data and accounts which I care about, but the browser itself is also just a normal process subject to the attack described above.

I'm not really familiar with the Windows security model and what is possible, but is it an idea for the terminal process to run protected from injection and scraping by default?

Dustin L. Howett (MSFT) (@DHowett-MSFT)

Dustin L. Howett (MSFT) (@DHowett-MSFT) do we have a sudo megathread that combines all the 100 ways we've said no? Because we really should at this point

I have a maybe related question.
Would hosting a process of a powershell running on a remote machine through RemoteApp not be feasible for similar reason?

Could Windows Terminal instead treat the tabs as individual processes running as whatever user you choose? The host WindowsTerminal.exe could run as the current user but the tabs could have options to run as a separate user.

Honestly the lack of this feature will probably make or break my decision to even use this because I have a need to run PS as different users to properly secure environments and fulfill RBACs.

For the brave, let me introduce you a workaround based on gsudo, my open-source sudo for windows implementation. (MIT License)

Install gsudo, then add a new profile to Windows Terminal:

    {
      "guid": "{0667cbea-6f8d-43d6-b50a-e4f795569d86}",
      "name": "Elevated PowerShel",
      "commandline": "gsudo.exe PowerShell",
      "hidden": false
    },

This allows Windows Terminal to mix elevated and non-elevated consoles. Also, you can use gsudo to elevate simple commands from a non-elevated console.

At a minimum, I'd imagine the main terminal process would need to be elevated, or at least some kind of proxy process would need to be, but that means we'd then have to create a means of communication between the terminal, the proxy (which is a conpty server) and the elevated app (conpty client.) Things get hairy fast after that.

gsudo has an experimental ConPty mode, not enabled by default (use gsudo --vt [command]) that works pretty much that way. It spans the elevated process in a PseudoConsole and streams VT sequences to the non-elevated console.

Hosting a connection to an elevated process in a window owned by a medium-integrity (that is: not elevated) process is dangerous because any other medium-integrity process could possibly inject input into it or scrape output from it. That’s the sole reason we’ve been given by the windows security team to not endeavour to do this.

According to that criteria, is it safe to ssh root@otherserver from a non elevated console? Other non-elevated process could also inject or scrape ssh or the console.
Anyway, I've read this advice seriously and while I've already taken all security meassures that I could think of, I am totally open to criticism, advice, suggestions or bug reports.

EDIT: looks like linux sudo has always been vulnerable in this way. (I've only tested using WSL)

Gerardo Grignoli (@gerardog)

Gerardo Grignoli (@gerardog) Thanks for sharing the "gsudo" workaround (and for putting it together!!) I gave it a try, and it works well enough for my needs at this point. I don't know enough about how the security stuff works to know how big off on an issue it is to launch a new tab like this.

I have historically (and still do) use ConsoleZ, which really is a just a "wrapper" to launch hidden (launched off-screen at some large negative (-XXXXX, -XXXXX) coordinates, and then does some trickery with what is available to read and write to it (I have read there is screen scraping involved to read, but do not know the details.) This being the case, I assume each tab really is just interacting with its own Cmd, PowerShell, whatever process. I assume ConEmu and others do something similar.

I guess the question is, it sounds like Windows Terminal does not just wrap other processes. I know knowing about the evolving low-level Windows plumbing involved with this, so I don't know the issues involved. And I don't know for sure what the security concerns may be using "gsudo" as you outline above. For my usage cases, it gives me a quick elevated Cmd (or PowerShell) tab to get something, and then get out. Either way, thanks!

would something like this work? https://github.com/lukesampson/psutils/blob/master/sudo.ps1
tho i have no idea how you'd run it without Powershell

EDIT: looks like linux sudo has always been vulnerable in this way. (I've only tested using WSL)

When you do echo test > /dev/tty2 it first runs the echo command and then writes its output to /dev/tty2 so while it is possible for a lesser privileged process to write to a tty used by a high privileged process, it is not possible for the lesser privileged process to run a command with higher privileges.

I'm more concerned about whatever X11 allows than "i can write to a tty device" (which only impacts the output stream)

Spec for Windows Terminal Process Model 2.0 (#7240)

Glenn Sarti (@glennsarti)

Glenn Sarti (@glennsarti):

Thanks Dustin L. Howett (MSFT) (@DHowett-MSFT) ! (Yeah, my UWP isn't the best 😞 ) I've edited my original comment. One thing's that odd though. I can't save that I want to always elevate. I'm putting this down to UWP because the "Target type" isn't Application but the qualified APPX ID...

Create a fresh shortcut (right click desktop -> new shortcut) and enter wt.exe as the target. That will allow you enable "Run as Administrator". You can find an icon to use here in the directory res

Random thought: wouldn't it be possible, in Windows, to allow unelevated app to opt-in to UIPI (via the app manifest, for example) so that they are effectively isolated like admin apps, while still not actually running as admin?

That would resolve the scraping/injection concern, opening up the possibility to run mixed tabs elevation.

Charles Milette (@sylveon)

Charles Milette (@sylveon) That's maybe possible, though I don't know about that too much. Would that break screen readers or other accessibility tools? Or even IMEs? I'd love to see a proof-of-concept!

Screen readers, IMEs and other accessibility tools already use UI Access to punch a hole in UIPI, so there shouldn't be much of an issue here.

However I can't come up with a PoC because it would require platform support (afaik) and I'm not a Windows developer yet ;)

Huh. Shame I'm on leave for the next month, otherwise I'd give it a go. Maybe when I get back...

Oh wait, nevermind. That's why this won't work:

UIPI doesn't interfere with or change the behavior of messages between applications at the same privilege (or integrity) level.

so the problem here is

High-IL:                  cmd.exe
                            ↕
Med-IL: malicious.exe --> wt.exe

OH I see - you're suggesting that we modify UIPI to enable this scenario, rather than "this is something that you can do as an app developer today". Okay. That makes more sense. I'm all over the place today. Sorry for the confusion.

Indeed, I was suggesting modifying UIPI in the OS itself to support this scenario: blocking the communication between malicious.exe and wt.exe even at the same (or lower) IL

Spec for Elevation QOL improvements (#8455)

Navigation Menu

Repository navigation

Megathread: sudo, runas, mixed elevation of tabs, etc. #1032

Summary of the new feature/enhancement

Proposed technical implementation details (optional)

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Megathread: sudo, runas, mixed elevation of tabs, etc. #1032

Description

Summary of the new feature/enhancement

Proposed technical implementation details (optional)

Activity

oising commented on May 27, 2019

mdtauk commented on May 27, 2019

oising commented on May 27, 2019

mdtauk commented on May 27, 2019

hansmbakker commented on May 27, 2019

DHowett-MSFT commented on May 27, 2019

hansmbakker commented on May 27, 2019

mdtauk commented on May 27, 2019

sedwards2009 commented on May 28, 2019

zadjii-msft commented on May 28, 2019

13 remaining items

alefranz commented on Aug 23, 2019

yllekz commented on Nov 15, 2019

gerardog commented on Jan 16, 2020

ossdesign commented on Apr 4, 2020

grave0x commented on May 1, 2020

matthew4850 commented on Jun 22, 2020

DHowett commented on Jun 22, 2020

darealshinji commented on Feb 14, 2021

sylveon commented on May 28, 2021

zadjii-msft commented on May 28, 2021

sylveon commented on May 28, 2021

zadjii-msft commented on May 28, 2021

sylveon commented on May 28, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions