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

[hansmbakker]

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

[oising]

@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.

[mdtauk]

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

[oising]

@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.

[mdtauk]

@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.

[hansmbakker]

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

[DHowett-MSFT]

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.

[hansmbakker]

Thanks for being transparent about it.

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

[mdtauk]

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.

[sedwards2009]

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?

[zadjii-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

[zadjii-msft]

Congratulations, this is the sudo megathread now. (I liked this number the most of all the issues that currently existed.)

Real quick linking all the other issues I can find that are related:
#691 #632 #146

[thomassth]

Please re-open this thread as I think this is a solvable problem, not an impossibility.

Copying from another thread, since I see no one object this idea yet:

"Open Terminal as Admin" at the dropdown list

• Same behavior as in File Explorer (and many other Linux file managers)
• No tab mixing, one window elevated, one window not elevated
• Bind to keyboard shortcut for simple navigation
• Allow user config to open specific elevated environment / location, with keyboard shortcut
• For god sake this is a solved solution just let the users have it
  

[glennsarti]

@thomassth

Disclaimer - I am not a developer etc. on the terminal project, just a user. And my knowledge of UWP is cursory at best.

Trying to add a " ... as a administrator" shortcut is unfortunately going to be difficult because the Windows Terminal application is not a "traditional" win32 app (like PowerShell or cmd.exe), it's packaged as a UWP application. And UWP is specifically does not allow this. For example

EDIT - Terminal isn't UWP, it's packaged as a UWP.

Your application always runs with elevated security privileges. Your application needs to work while running as the interactive user. Users who install your application from the Microsoft Store may not be system administrators, so requiring your application to run elevated means that it won't run correctly for standard users. Apps that require elevation for any part of their functionality won't be accepted in the Microsoft Store.

Ref - https://docs.microsoft.com/en-au/windows/msix/desktop/desktop-to-uwp-prepare

Elevation

The allowElevation restricted capability allows apps that are created by Microsoft partners and enterprises to preserve existing desktop functionality that requires auto-elevation on launch or during an app‘s lifetime.

We don't recommend that you declare this capability in applications that you submit to the Microsoft Store. In most cases, the use of this capability won't be approved. It will only be approved for line-of-business apps deployed by enterprises to their private store via the Microsoft Store for Business.

Ref - https://docs.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations

HOWEVER all hope is not lost. UWPs can't just be started from the commandline, for example running C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1715.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe from the command line will result in an "Access Denied"

But you CAN start them via the APX Activation Manager. This gist

https://gist.github.com/ridomin/e222147e7b6891e5df086cce6b5dc218#file-startuwpfromcommandline-ps1-L150-L165

Shows a powershell way to run an arbitrary UWP app. So you could run Start-Locally -ID Microsoft.WindowsTerminal FROM an already elevated process (or say, a contrived shortcut) run the parent process in an elevated context.

[DHowett-MSFT]

@glennsarti you’re partially right. The terminal isn’t a UWP, but it is MSIX-packaged like one. Because it’s not a UWP, though, you can just use “Run as administrator” on it. The thing it doesn’t, and probably cannot safely (per discussion above) support is running processes from multiple integrity levels in the same session.

[glennsarti]

Thanks @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...

I added a "Standard" shortcut for comparison in the screenshot.

The thing it doesn’t, and probably cannot safely (per discussion above) support is running processes from multiple integrity levels in the same session.

Yup 100% agree.

[darealshinji]

@glennsarti:

Thanks @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

[sylveon]

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.

[zadjii-msft]

@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!

[sylveon]

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 ;)

[zadjii-msft]

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.

[sylveon]

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