Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Configuring Windows Terminal profile to always launch elevated #632

Closed
Tracked by #5000
pingzing opened this issue May 9, 2019 · 212 comments · Fixed by #12137
Closed
Tracked by #5000

[Question] Configuring Windows Terminal profile to always launch elevated #632

pingzing opened this issue May 9, 2019 · 212 comments · Fixed by #12137
Assignees
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.

Comments

@pingzing
Copy link
Contributor

pingzing commented May 9, 2019

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
Copy link
Member

zadjii-msft commented May 9, 2019

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
Copy link
Contributor Author

pingzing commented May 9, 2019

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
Copy link

mdtauk commented May 9, 2019

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

@zadjii-msft
Copy link
Member

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

@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@miniksa miniksa added Area-User Interface Issues pertaining to the user interface of the Console or Terminal Product-Terminal The new Windows Terminal. and removed Mass-Chaos labels May 17, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@miniksa miniksa added Area-Server Down in the muck of API call servicing, interprocess communication, eventing, etc. Needs-Tag-Fix Doesn't match tag requirements labels May 17, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@sba923
Copy link

sba923 commented May 23, 2019

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
Copy link

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
Copy link

LuisCor commented May 30, 2019

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
Copy link

@

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
Copy link

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
Copy link

sba923 commented Jul 17, 2019

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

@zadjii-msft zadjii-msft added Area-Settings Issues related to settings and customizability, for console or terminal Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. and removed Area-Server Down in the muck of API call servicing, interprocess communication, eventing, etc. Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Question For questions or discussion labels Jul 25, 2019
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Jul 25, 2019
@NoSubstitute
Copy link

my default profile is set to bash rather than powershell, and i'd like to keep it that way.

Me too. I run WSL most of the time, but every now and then I need to run PS elevated, and I'd like to do it in a tab of the new WT.

@ayfine
Copy link

ayfine commented Aug 30, 2020

I was also unable to get any of the examples to work - even with correcting my file paths. I found and installed gsudo which can elevate the current tab, or be used as a profile to open an elevated tab in the same window. I am unsure if the solutions above started in a new window (some attempts I made before using gsudo would only start in a new window). It will open an UAC popup.

This is the profile I am using:

{
    // Elevated Powershell using gsudo
    // https://github.com/gerardog/gsudo
    "name": "Elevated PowerShell",
    "commandline": "powershell.exe gsudo powershell.exe -nologo",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png",
    "suppressApplicationTitle": true
}

I am using supressApplicationTitle so that the tab title not display Administrator: as its redundant with Elevated.

@bb010g
Copy link

bb010g commented Aug 30, 2020

@ayfine If #632 (comment) is indeed not working for you, could you send a transcription of the exact errors / unexpected behavior you're getting with that config? (Make sure to add in extra configuration, like suppressApplicationTitle, in as small as steps as possible, so that if any of your configuration is breaking WT it'll be easier to tell where & when it's happening.)

If any other configurations here got slightly further than the linked one for you, details on how those are breaking would also be appreciated.

@ayfine
Copy link

ayfine commented Aug 30, 2020

@bb010g I am not encountering any error messages - my apologies for not being more precise in my reply. When using #632 (comment) I ran in to the issue of Windows Terminal loading my WSL Ubuntu shell (my default). I had taken this originally to mean that it was not working correctly but I see now that in that new window, if I start a new (default profile) Powershell tab it is in fact elevated. Regardless, both by opening a new window and having to start a new tab within that, it's not any easier than running an elevated process from my start menu. What I described in my original reply provides with the exact behavior I was imagining.

@NoSubstitute
Copy link

@ayfine - and I copied your gsudo example. That's a good-enough solution until something built-in is coded. Thanks.

@MikeChristensen

This comment has been minimized.

@DHowett
Copy link
Member

DHowett commented Sep 1, 2020

If you are having issues with gsudo please report them to @gerardog and not in this thread. Every message on this thread (this one included; sorry!) e-mails hundreds of subscribers.

I am going to lock this thread to further non-maintainer comments, as we are reaching the point where further comments aren’t moving the discussion forward a meaningful amount.

Please file new issues if you have concerns that are not covered here.

@microsoft microsoft locked as off-topic and limited conversation to collaborators Sep 1, 2020
@zadjii-msft zadjii-msft added this to Spec Needed ❓ in Specification Tracker via automation Nov 23, 2020
@zadjii-msft zadjii-msft self-assigned this Nov 23, 2020
@zadjii-msft zadjii-msft moved this from Spec Needed ❓ to Spec In Progress ✏ in Specification Tracker Nov 23, 2020
@zadjii-msft zadjii-msft moved this from Spec In Progress ✏ to Spec In Review ⏰ in Specification Tracker Dec 1, 2020
@zadjii-msft zadjii-msft moved this from In Review to In progress in Process Model Improvements Dec 14, 2020
@zadjii-msft zadjii-msft moved this from Spec In Review ⏰ to Spec Accepted! 🎉 in Specification Tracker Aug 25, 2021
@zadjii-msft zadjii-msft moved this from In progress to Elevation To Do in Process Model Improvements Aug 25, 2021
@zadjii-msft zadjii-msft moved this from Elevation To Do to In progress in Process Model Improvements Aug 31, 2021
@zadjii-msft zadjii-msft moved this from In progress to In Review in Process Model Improvements Sep 22, 2021
@zadjii-msft zadjii-msft linked a pull request Sep 29, 2021 that will close this issue
4 tasks
@zadjii-msft zadjii-msft added the In-PR This issue has a related PR label Sep 29, 2021
@ghost ghost removed the In-PR This issue has a related PR label Jan 11, 2022
@ghost ghost closed this as completed in #12137 Jan 12, 2022
Process Model Improvements automation moved this from In Review to Done Jan 12, 2022
ghost pushed a commit that referenced this issue Jan 12, 2022
## Summary of the Pull Request

This is the resurrection of #8514 and #11310. WE determined that we didn't want to do #11308 after all, so this should be profile auto-elevation, without the warning.

This PR adds two features:
* the `elevate: bool` property to profiles
  - If the user is running unelevated, **and** `elevate` is set to `true`, then instead of opening a new tab, we'll open an elevated Terminal window with the profile.
  - Otherwise, we'll just open a new tab in the existing window. This includes cases where the window is elevated, and the profile is set to `elevate:false`. `elevate:false` basically just means "do nothing special with me".
* the `elevate: bool?` property to `NewTerminalArgs` (`newTab`, `splitPane`)
  - This allows a user to create an action that will elevate the profile, even if the profile is not otherwise set to auto-elevate.
  - `elevate:null` (_the default_) does not change the profile's elevation status. The action will use whatever is set by the profile.
  - `elevate:true` will attempt to auto-elevate the profile
  - `elevate:false` will do nothing special. 


## References
* #5000 for obvious reasons
* Spec'd in #8455

## PR Checklist
* [x] Closes #632
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - sure does, but that'll come all at the end.

## Detailed Description of the Pull Request / Additional comments

After playing with de-elevation a bit, it turns out it behaves weirdly with packaged applications. I can try and ask `explorer.exe` to launch the process on our behalf. However, if the thing we're launching is an execution alias (`wt.exe`), and we're elevated, then the child process will _still launch elevated_. 

There's also something super BODGEY at work here. `ShellExecute` is the function we use to ask the OS to elevate something for us. But `ShellExecute` needs to be able to send a window message to the process that called it (if the caller was a WINDOWS subsystem application). So if we die immediately after calling `ShellExecute`, then the elevated process never actually spawns - sad. So we're adding a helper process, `elevate-shim.exe`, that lives in our process. That'll be the one that actually calls `ShellExecute`, so that it can live for the duration of the UAC prompt.

## Validation Steps Performed

* Ran tests
* Opened a bunch of terminal tabs at various different elevation levels
* opened new splits too
* In the defaults (base layer) as well, for madness 

Some settings to use for testing

<details>

```jsonc
    "keybindings" :
    [
        ////////// ELEVATION ///////////////
        { "keys": "f1", "name": "ELEVATED TAB", "icon": "\uEA18", "command": { "action": "newTab", "elevate": true } },
        { "keys": "f2", "name": "ELEVATED, Color", "icon": "\uEA18", "command": {
            "action": "newTab", "elevate": true, "commandline": "PowerShell.exe", "startingDirectory": "C:\\Windows", "tabColor": "#bbaa00"
        } },
        { "keys": "f3", "name": "unelevated ELEVATED", "icon": "🙃", "command": {
            "action": "newTab", "elevate": false, "profile": "elevated cmd"
        } },
        //////////////////////////////
    ],

    "profiles":
    {
        "defaults":
        {
            "elevate": true,
        },
        "list":
        [
            {
                "hidden":false,
                "name" : "cmd",
                "commandline" : "cmd.exe",
                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
                "startingDirectory" : "%USERPROFILE%",
                "opacity" : 20
            },
            {
                "name" : "the COOLER cmd",
                "commandline" : "c:\\windows\\system32\\cmd.exe",
                "startingDirectory" : "%USERPROFILE%",
            },
            {
                "name" : "the sneaky cmd",
                "commandline" : "c:\\windows\\system32\\cmd.exe /k echo sneaky sneaks",
                "startingDirectory" : "%USERPROFILE%",
            },
            {
                "name": "elevated cmd",
                "commandline": "cmd.exe /k echo This profile is always elevated",
                "startingDirectory" : "well this is garbage",

                "elevate": true,
                "background": "#9C1C0C",
                "tabColor": "#9C1C0C",
                "colorScheme": "Desert"
            },
            {
                "name": "unelevated cmd",
                "commandline": "cmd.exe /k echo This profile is just as elevated as you started with",
                "elevate": false,
                "background": "#1C0C9C",
                "tabColor": "#1C0C9C",
                "colorScheme": "DotGov",
                "useAcrylic": true
            },
        ]
```

</details>

Also try:
* `wtd nt -p "elevated cmd" ; sp -p "elevated cmd"`
* `wtd nt -p "elevated cmd" ; nt -p "elevated cmd"`




This was merged manually via 

```
git diff dev/migrie/f/non-terminal-content-elevation-warning dev/migrie/f/632-on-warning-dialog > ..\632.patch
git apply ..\632.patch --ignore-whitespace --reject
```
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.
Projects
Specification Tracker
  
Spec Accepted! 🎉