[Question] Configuring Windows Terminal profile to always launch elevated

[pingzing]

Hi! Is there a way to configure a profile so that the commandLine it launches always starts with elevated (admin) permissions?

Currently, you can launch the entire application as Administrator, but then every single commandLine runs as Administrator, which is not ideal.

[zadjii-msft]

There is not. I don't think we plan on supporting mixed elevated and unelevated tabs, because it's a bit of a security hole.

Yes I know sudo is a thing, but we've had lots of discussions with the security team about the creation of a sudo for Windows. The main problem is due to the fact that any unelevated processes can send keystrokes to any other unelevated windows.

If you had an elevated commandline running in an unelevated window, an untrusted bad actor could execute an elevation-of-privilege attack by driving the unelevated windows that's running the elevated commandline.

(as a matter of linking related threads, #146)

---

EDIT (Feb 14 2020) Okay, so this comment didn't age super well. Originally, there was no plan to support this, since it wouldn't work with the single HWND we had. We're working on designing a solution that might support this in the future, but we can't commit to anything until we're sure that we can come up with an appropriately secure solution, that ensures that a lower privileged process can't drive a higher privilege terminal.

[pingzing]

Seems reasonable. I think having something like a combination of #576 (Open as Admin in the jump list), and maybe some kind of hotkey to launch an Admin session of the Terminal would solve most of my pain here.

[mdtauk]

What about having a standard and elevated Terminal open in a single window but separate tabs?

[zadjii-msft]

@mdtauk I think that unfortunately falls under the same category. Since all the tabs are under the same HWND, the root HWND is what would need to be elevated to prevent non-elevated apps from driving the window.

[sba923]

From a security standpoint (ignoring Windows Terminal's design, single root HWND etc.), how "less secure" is Terminal running mixed-elevation tabs compared to running, say, one elevated PowerShell instance next to one non-elevated one in the current UX? The fact the console apps are hosted in Terminal tabs doesn't make a difference to me...

[dasMulli]

On a similar note: How is having a non-elevated window more secure even if I open a remote PS session where I may now have admin privileges on a remote server that a non-elevated could now drive. For me this seems much worse than gaining local admin access, so I don't think that running a tab as admin is any different than remoting / ssh-ing into other servers. In both cases, I need to feel comfortable enough with my system to do it. It's an "I'm old enough and I understand the risks" thing.

[LuisCor]

Whenever I try to run the Terminal app with an administrator account, right click -> run as administrator, the UAC pops up twice and an error occurs saying: "Windows cannot find (path\WindowsTerminal.exe) Make sure you typed ...".

The path exists and the app works correctly for the non admin user that built the app, but the other administrator user is unable to run it. If I login to the admin user the terminal app is not present in either the settings or the start menu, as if it was never installed on the system.

Is there a way to build the app so that it installs for all users? Or does the root of the project have to be on a non user specific directory?

[mhouston100]

@

Whenever I try to run the Terminal app with an administrator account, right click -> run as administrator, the UAC pops up twice and an error occurs saying: "Windows cannot find (path\WindowsTerminal.exe) Make sure you typed ...".

The path exists and the app works correctly for the non admin user that built the app, but the other administrator user is unable to run it. If I login to the admin user the terminal app is not present in either the settings or the start menu, as if it was never installed on the system.

Is there a way to build the app so that it installs for all users? Or does the root of the project have to be on a non user specific directory?

I'm seeing the same issue happening also.

Windows version 18922.1000

[cking22001]

Right, so running store apps as admin or different user is not working (by design BTW). Many of us are logged in (to PC) as a normal non-elevated account. We run powershell/cmd/etc as an admin to do certain tasks.

If the final choice is to deploy this app is the Windows store, it is useless to me without some way to open elevated tabs. My 2 cents.

[sba923]

"Useless" is maybe a bit harsh, but indeed we do need a way to use the new terminal both for non-elevated and for elevated console apps / shells. And for me the best UX would be to support a mix of elevated and non-elevated tabs in the same Windows Terminal instance. Less preferable: support zero to many (typically one) elevated instances (each with one to many tabs) alongside zero to many (typically one) non-elevated instances.

[pratnala]

ConEmu is able to mix elevated and non-elevated tabs in the same window. Can't something like that be done here?

[shmuelie]

Could we have an elevated Terminal launch non-elevated tabs? I still need to launch elevated BUT I can open a new tab that's "protected".

[WSLUser]

If we want to go very Windows-specific and ignore other platforms that may eventually see Terminal, perhaps usage of Windows Containers or virtualized processes could help this pain point for some. I personally am just fine with current solution but getting console apps to run as a isolated processes by default wouldn't be such as bad idea from security point of view.

[kort3x]

Mixed elevation in one window is a must, for me at least. Could it be an optional feature to be toggled in settings?

[oising]

@pratnala With ConEmu it only looks like it's doing that, but it's not really doing that at all. The elevated and unelevated "tabs" are just views into two completely separate, isolated root windows/processes. It does this by scraping the windows' contents among other things and proxy/broker elevation helpers etc . Sure, it's technically possible, but what ConEmu does is actually kinda unsafe. It's one thing for a third party program to do this and have people opt into the risk by downloading ConEmu, but quite another for Microsoft to officially endorse this by doing this itself. If I want to hide my front door keys under the doormat, then fine - that's my dumb risk to take. But what if every door you bought put a set of keys under the doormat?

[robomac]

But see, I develop in C++ (and C#, PowerShell, Ruby, Python, GoLang, pretty much anything that comes my way.) I have ConEmu and TakeCommand installed, along with mingw. I know which way to hold the scissors while I run.

PowerShell is a security hole. A very useful automation tool, allowing all sorts of unexpected access. And what we're asking for (mixed modes) is certainly safer than the alternative (all elevated.) Really this (terminal) is a power tool for power users, most of whom probably understand the security landscape extremely well... and understand pragmatic compromise.

Zero-trust only works when it's not debilitating.

[DHowett-MSFT]

@robomac If we could convince the security team (who has told us on multiple occasions to not even venture remotely close to mixed elevation) that only people who know how to hold their scissors the right way and not run with them would use this project, we'd probably do it. I don't know if I believe it myself. Here's why:

Like as not, if Terminal is running in mixed elevation (from a Medium-IL host to a High-IL client), it can still be forced to receive input by anything else running as that user. Even if the person behind the keyboard is a saint and only elevates for the ten seconds she needs to elevate for, any application running under her user account can impersonate the administrator without an additional elevation prompt. Likely entirely undetected, even.

[robomac]

@DHowett-MSFT I thank you for responding. You make an assumption that we are allowing malicious processes running anyhow. We restrict permissions out of "Best Practices" mantras we do with our downward-facing-dog pose every morning, but if you really have a concern that a few hours, even, of elevated terminal access puts you at risk on your own system that you're developing on ...

1. You shouldn't be running Terminal and
2. You should wipe and start over.

I'll grant you that a (computer) virus researcher shouldn't risk this in a vector path... but even early on we were sandboxing them in VMs. But "Terminal" isn't for your unsavvy relatives; it's a power tool.

There is a standard way of dealing with the risk. Brought to you by the browser world. When you go to the advanced flags, you receive a warning of, roughly, "Here be dragons". (I think it's precisely that in Pale Moon... which is the serious hard-core security browser.) Add the (non-UAC, additional) warning, but let the user decide.

One other question: Would two distinct sessions of Terminal, one elevated, one not, behave as expected? Or would both be vectors for any sessions?

[DHowett-MSFT]

I don't disagree that people should be able to opt into something like this. :smile:

two distinct sessions

Oh, yeah, that should absolutely work today -- and not be a vector (the elevated one is fully running on the High-IL side of the world and cannot be driven by any other Medium-IL process)

[pratnala]

that should absolutely work today

In the same spirit, can't 2 tabs run in different processes and thus enable mixed elevation in the same window?

[robomac]

@DHowett-MSFT So why can't the two distinct sessions be hosted in the over-arching app? It really isn't hard to do.

[sba923]

I think I understand the security implications of having elevated console apps in the first place, but what I can't grasp is why having two types of tabs (elevated and non-elevated) within Windows Terminal would be more risky than what Windows has supported for ages i.e. running elevated and non-elevated CMD's / PowerShell's side-by-side. Can someone shed some light on this?

[DHowett-MSFT]

@robomac [1] It is trivial when you are hosting traditional windows with traditional window handles. That works very well in the conemu case, or in the tabbed shell case, where you can take over a window in an elevated session and re-parent it under a window in a non-elevated session.

When you do that, there's a few security features that I'll touch on in [2]. Because of those, you can parent it but you can't really force it to do anything.

There's a problem, though. The Terminal isn't architected as a collection of re-parentable windows. For example, it's not running a console host and moving its window into a tab. It was designed to support a "connection" -- something that can read and write text. It's a lower-level primitive than a window. We realized the error of our ways and decided that the UNIX model was right the entire time, and pipes and text and streams are where it's at.

Given that we're using Xaml islands to host a modern UI and stitching a DirectX surface into it, we're far beyond the world of standard window handles anyway. Xaml islands are fully composed into a single HWND, much like Chrome and Firefox and the gamut of DirectX/OpenGL/SDL games. We don't have components that can be run in one process (elevated) and hosted in another (non-elevated) that aren't the aforementioned "connections".

Now, the obvious followup question is "why can't you have one elevated connection in a tab next to a non-elevated connection?" This is where @sba923 should pick up reading (:smile:). I'm probably going to cover some things that you (@robomac) know already.

[2] When you have two windows on the same desktop in the same window station, they can communicate with eachother. I can use SendKeys easily through WScript.Shell to send keyboard input to any window that the shell can see.

Running a process elevated severs that connection. The shell can't see the elevated window. No other program at the same integrity level as the shell can see the elevated window. Even if it has its window handle, it can't really interact with it. This is also why you can't drag/drop from explorer into notepad if notepad is running elevated. Only another elevated process can interact with another elevated window.

That "security" feature (call it what you like, it was probably intended to be a security feature at one point) only exists for a few session-global object types. Windows are one of them. Pipes aren't really one of them.

Because of that, it's trivial to break that security. Take the terminal as an example of that. If we start an elevated connection and host it in a non-elevated window, we've suddenly created a conduit through that security boundary. The elevated thing on the other end isn't a window, it's just a text-mode application. It immediately does the bidding of the non-elevated host.

Anybody that can control the non-elevated host (like WScript.Shell::SendKeys) also gets an instant conduit through the elevation boundary. Suddenly, any medium integrity application on your system can control a high-integrity process. This could be your browser, or the bitcoin miner that got installed with the left-pad package from NPM, or really any number of things.

It's a small risk, but it is a risk.

---

Other platforms have accepted that risk in preference for user convenience. They aren't wrong to do so, but I think Microsoft gets less of a "pass" on things like "accepting risk for user convenience". Windows 9x was an unmitigated security disaster, and limited user accounts and elevation prompts and kernel-level security for window management were the answer to those things. They're not locks to be loosened lightly.

[sba923]

@DHowett-MSFT Thank you so much for the clarification. I think we'll have to get used to running one elevated instance of Windows Terminal and one non-elevated instance side-by-side, much like we're doing with console apps these days.

[robomac]

Fascinating. Thank you. Terminal being more a connection-renderer than a window does make sense. Does that give PowerShell, already rather pipe/connection focused, any additional control over previously in a windowed console?

Are separate Terminal sessions fully isolated from each-other?

[damnsalvation]

I'd be entirely satisfied with just having an indication that I'm in an elevated session. Like "Administrator: \<whatever>" I'm missing that pretty bad right about now.

[DHowett-MSFT]

???

[Fisico]

"Run as different user" is a thing all windows admins need! This would be very helpful if it is available. The best option would be to have it with a flag in the config for each profile.

[ecki]

BTW, speaking of window isolation, let me quote the latest ctfmon vulnerability report

The obvious attack is an unprivileged user injecting commands into an Administrator's console session, or reading passwords as users log in. Even sandboxed AppContainer processes can perform the same attack.

[oising]

@ecki That is quite a disturbing piece of news alright. I'm sure Tavis is off partying tonight after that one.

[Fisico]

@DHDHowett-MSFT As many here have written, if the new terminal is not able to start with option "run as different user" than for a big number of users it is not very usable, also it is not compatible with Microsoft’s “Active Directory administrative tier model” if you for example have an AD user with default rights, and run PS Scripts with an Adminuser on a domain controller.

I don’t have many cases where I start a terminal with my currently logged in user… so I ask you, what is the use case of this Terminal than? Ping, nslookup etc,.. if that is the intention than why are you putting so much work into all this?

With “run as Administrator” you have some valid points, but why other Consoles like (PS6/7) still support these functions, if it is that insecure?

I always thought the new Terminal App will replace all the separate cmd/PS/… windows, but as it seems it is not usable in many real world scenarios. This is kind of sad tbh...

[DHowett-MSFT]

@Fisico your experience is not universal, and I’d encourage you to consider that when asking somebody to justify their project’s very existence.

[DHowett-MSFT]

To your overarching point about "run as different user" not existing/not working: that's a platform limitation that we're trying to get lifted. It's not through malice or incompetence that we do not support it.

As for why other console applications do support it, it is not insecure when they do because they are specifically not hosting different elevation levels in the same window. That's the core issue here. Because they are hosted in standalone processes with standalone windows, they are free from the restriction on cross-integrity-level manipulation.

[Fisico]

@DHowett-MSFT Sorry if I offended you with my post, it was not my intention, I put too much emotion into it. I think the Terminal is a great idea and has a very big potential and I’m glad you are developing it with the community to get the most out of it.

At this point there is so much confusion on what is implemented and what not. “Run as Administrator” for the whole app is working at the moment, is this here to stay?

As I understand, “Run as Administrator” for each tab/profile is not something you want to implement. I think this ok for most of us.

“Run as different user” is not possible because Windows does not support it for apps, and you/we have to wait until Windows supports it? If so are we speaking of years?

“Run as different user” per tab/profile is also something you do not want to implement?

[robomac]

@DHDHowett-MSFT As many here have written, if the new terminal is not able to start with option "run as different user" than for a big number of users it is not very usable, ... I always thought the new Terminal App will replace all the separate cmd/PS/… windows, but as it seems it is not usable in many real world scenarios. This is kind of sad tbh...

I don't agree. This is a huge advance over what we had before. Unfortunately, most of us probably have gotten in the habit of running our shells elevated because of lack of a more granular approach... and we still can. We can't mix them... but we never did. Seriously, at the last three companies I've been at, the Developer Wiki has doing all builds/tests in an elevated VS prompt. We implement security through real-time scans, aggressive active firewalls and knowing that our developers seldom screw up. The non-developers never run elevated, because (1) we can't trust them and (2) they don't need to.

So I, for one, am appreciative of this new Terminal. It's not perfect, but neither is Take Command / TCC. At least this is standard.

[Fisico]

@DHDHowett-MSFT As many here have written, if the new terminal is not able to start with option "run as different user" than for a big number of users it is not very usable, ... I always thought the new Terminal App will replace all the separate cmd/PS/… windows, but as it seems it is not usable in many real world scenarios. This is kind of sad tbh...

I don't agree. This is a huge advance over what we had before. Unfortunately, most of us probably have gotten in the habit of running our shells elevated because of lack of a more granular approach... and we still can. We can't mix them... but we never did. Seriously, at the last three companies I've been at, the Developer Wiki has doing all builds/tests in an elevated VS prompt. We implement security through real-time scans, aggressive active firewalls and knowing that our developers seldom screw up. The non-developers never run elevated, because (1) we can't trust them and (2) they don't need to.

So I, for one, am appreciative of this new Terminal. It's not perfect, but neither is Take Command / TCC. At least this is standard.

elevated != run as different user. I run PowerShell more with other AD users, then with my own one. I’m with you that you often run a cmd or PS as admin even if you don’t have to, but there are so many cases where you have to run it as admin. Most sysadmin tasks require admin rights or a different user with some sort of privileges. Sure if you need to run cmd’s in user context it is all ok.

[robomac]

I understand that "elevated != run as different user". I just don't believe "run as different user" is nearly as common as you claim.

[Fisico]

I understand that "elevated != run as different user". I just don't believe "run as different user" is nearly as common as you claim.

If you have something to do with the Microsoft universe than you absolutely need it. It is not the best idea to login to windows machines with domain admin rights for example. Running PS scripts with a user that has domainadmin rights or some other rights is very common.

[shmuelie]

@Fisico why not use the New-PSSession command then?

[WSLUser]

Automated scripts that require some type of specific elevation for a service typically require 'run as different user'. Whether that applies to Terminal is a different story. You can always change your login once in a CMD or PS session using the runascommand. This would not change the elevation state of the tab as it's utilizing the underlying login, which is your regular user. Also any scripts you'd run using Task Scheduler or a cron job won't require Terminal to run unless you're utilizing it to get a functionality that somehow doesn't exist in a normal console session. If that's the case, the utilization of parameters to run that script with Terminal, which launches as a background process would be the solution.

Therefore mixed elevation for tabs isn't necessary. We have a workaround and it's easy enough to copy the specific runas commands you need to a txt file that you can copy/paste into the Terminal and then fill out your password (you should never save your password to anything that's unencrypted).

[Fisico]

@SamuelEnglard i don't want to connect to a remote host, to run a script.

@WSLUser yea it is a option to use runas, but it is much more convenient to simply run the terminal or PS as a different user. I don't see why this should be a problem.

[shmuelie]

@Fisico New-PSSession doesn't need to connect to a remote computer, see the secondfirst syntax entry.

[jkavanagh58]

@SamuelEnglard i don't want to connect to a remote host, to run a script.

@WSLUser yea it is a option to use runas, but it is much more convenient to simply run the terminal or PS as a different user. I don't see why this should be a problem.

It is pretty standard operation for a user to pin PowerShell to taskbar and Right-Click to run as Admin or in some environments RunAs OtherUser as an elevated account is needed to run and enterprise level script. To say not possible for terminal is like the environments that leverage PSLockDown and force RunAs Admin just to load the shell or VSCode IMHO

[shmuelie]

If you really need to have a tab run as a different user you could have a profile that runs New-PSSession -Credential | Enter-PSSession at start.

DISCLAIMER: I take no responsibility for computers ruined from doing this.

[jkavanagh58]

If you really need to have a tab run as a different user you could have a profile that runs New-PSSession -Credential | Enter-PSSession at start.

DISCLAIMER: I take no responsibility for computers ruined from doing this.

Sure, or the "security" standing here could be re-considered. Again, I pin PowerShell to my Task bar, from there I can launch PowerShell non-elevated; I can right-click that and choose "Run As Administrator" and if in a corp environment I can Right-Click on the icon, then Shift-Right-Click on "Windows PowerShell" and select "Run as Different User" to launch PowerShell with alternate credentials. No sessions, no RDP'ing to another host to obtain those creds.

[shmuelie]

Sure, or the "security" standing here could be re-considered. Again, I pin PowerShell to my Task bar, from there I can launch PowerShell non-elevated; I can right-click that and choose "Run As Administrator" and if in a corp environment I can Right-Click on the icon, then Shift-Right-Click on "Windows PowerShell" and select "Run as Different User" to launch PowerShell with alternate credentials. No sessions, no RDP'ing to another host to obtain those creds.

Yes, and I can also do that with Windows Terminal. Agreed. I don't see how that helps those who want to have a mix of tabs that are running as different users (or different elevation).

[cking22001]

"mixed tabs" aside, I just want to clarify, you CANNOT do that with (the released preview) Windows Terminal due to the design of Windows Store apps. You can only run as the user that installed that app and logged in as that same user.

All I want is to be able to do what I do today, log onto the PC as normal user and run elevated shells. If Windows Terminal is released as is, it is little use to me.

[sba923]

Very good point. This limitation doesn't exist with private (non-store) builds of Windows Terminal.

[pratnala]

"mixed tabs" aside, I just want to clarify, you CANNOT do that with (the released preview) Windows Terminal due to the design of Windows Store apps. You can only run as the user that installed that app and logged in as that same user.

All I want is to be able to do what I do today, log onto the PC as normal user and run elevated shells. If Windows Terminal is released as is, it is little use to me.

I just opened 2 instances of the store build of Windows Terminal - one elevated, and one not. So I don't know why is it not working for you.

[cking22001]

Ok, I have to believe you are a local admin on your PC. To be clear, maybe I should clarify. I am never a local admin on my workstation. So when I go to 'run as admin' I am prompted for user/password.

The 'admin' account I use is different from my normal malware/email reading account. So technically what I do is run as different user. This is the Windows Store app limitation. The solution (and maybe they will do this) is to release this as a Windows component that won't have those limitations.