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

@oising commented on GitHub (May 27, 2019):

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

@oising commented on GitHub (May 27, 2019): @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.

claunia commented

@mdtauk commented on GitHub (May 27, 2019):

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

@mdtauk commented on GitHub (May 27, 2019): Couldn't each tab run in it's own isolated process - with some being elevated, and others not - but in the same Window?

claunia commented

@oising commented on GitHub (May 27, 2019):

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

@oising commented on GitHub (May 27, 2019): @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.

claunia commented

@mdtauk commented on GitHub (May 27, 2019):

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

@mdtauk commented on GitHub (May 27, 2019): @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.

claunia commented

@hansmbakker commented on GitHub (May 27, 2019):

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

@hansmbakker commented on GitHub (May 27, 2019): It's a pity that it is unfeasible, but thank you for your explanation.

claunia commented

@DHowett-MSFT commented on GitHub (May 27, 2019):

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.

@DHowett-MSFT commented on GitHub (May 27, 2019): > 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.

claunia commented

@hansmbakker commented on GitHub (May 27, 2019):

Thanks for being transparent about it.

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

@hansmbakker commented on GitHub (May 27, 2019): Thanks for being transparent about it. On the technical side, I’m wondering why `sudo` works while what I asked for can cause risks?

claunia commented

@mdtauk commented on GitHub (May 27, 2019):

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.

@mdtauk commented on GitHub (May 27, 2019): > 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.

claunia commented

@sedwards2009 commented on GitHub (May 28, 2019):

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?

@sedwards2009 commented on GitHub (May 28, 2019): > 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?

claunia commented

@zadjii-msft commented on GitHub (May 28, 2019):

@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 commented on GitHub (May 28, 2019): @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

claunia commented

@zadjii-msft commented on GitHub (May 29, 2019):

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

@zadjii-msft commented on GitHub (May 29, 2019): 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

claunia commented

@thomassth commented on GitHub (Jun 24, 2019):

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:

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

@thomassth commented on GitHub (Jun 24, 2019): 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 ![image](https://user-images.githubusercontent.com/8331853/59994086-28276d00-9685-11e9-81e6-2c3bb6f9c760.png)

claunia commented

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

@glennsarti commented on GitHub (Jul 1, 2019):

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

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.

@glennsarti commented on GitHub (Jul 1, 2019): @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.

claunia commented

@DHowett-MSFT commented on GitHub (Jul 1, 2019):

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

@DHowett-MSFT commented on GitHub (Jul 1, 2019): @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.

claunia commented

@glennsarti commented on GitHub (Jul 1, 2019):

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.

@glennsarti commented on GitHub (Jul 1, 2019): 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. ![image](https://user-images.githubusercontent.com/5819622/60410088-0b48e780-9bf9-11e9-8290-1d9666c972ff.png) > 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.

claunia commented

@chucker commented on GitHub (Jul 1, 2019):

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

Is there no facility for a cross-process framebuffer (like macOS's IOSurface, and perhaps like Chromium's architecture)? Or is the problem that such processes must be from the same login session?

@chucker commented on GitHub (Jul 1, 2019): >The thing it doesn’t, and probably cannot safely (per discussion above) support is running processes from multiple integrity levels in the same session. Is there no facility for a cross-process framebuffer (like macOS's IOSurface, and perhaps [like Chromium's architecture](https://www.chromium.org/developers/design-documents/multi-process-architecture))? Or is the problem that such processes must be from the same login session?

claunia commented

@SHDMBelangerAlexandre commented on GitHub (Jul 3, 2019):

What I did to make as admin to work, I logged as my admin user, downloaded the App from the store and it was working. But I have other issue when there is an update. Not really the best way to do it imho.

@SHDMBelangerAlexandre commented on GitHub (Jul 3, 2019): What I did to make as admin to work, I logged as my admin user, downloaded the App from the store and it was working. But I have other issue when there is an update. Not really the best way to do it imho.

claunia commented

@mdtauk commented on GitHub (Jul 16, 2019):

Perhaps it should be treated in the same way as an "InPrivate" tab?

@mdtauk commented on GitHub (Jul 16, 2019): Perhaps it should be treated in the same way as an "InPrivate" tab?

claunia commented

@alefranz commented on GitHub (Aug 23, 2019):

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?

@alefranz commented on GitHub (Aug 23, 2019): 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?

claunia commented

@yllekz commented on GitHub (Nov 15, 2019):

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.

@yllekz commented on GitHub (Nov 15, 2019): 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.

claunia commented

@gerardog commented on GitHub (Jan 16, 2020):

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)

@gerardog commented on GitHub (Jan 16, 2020): For the brave, let me introduce you a workaround based on [`gsudo`](https://github.com/gerardog/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](https://github.com/gerardog/gsudo/issues). EDIT: looks like `linux sudo` has always been `vulnerable` in this way. (I've only tested using WSL) ![image](https://user-images.githubusercontent.com/3901474/72544102-8310f380-3865-11ea-96b1-0ce206f952ea.png)

claunia commented

@ossdesign commented on GitHub (Apr 4, 2020):

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

@ossdesign commented on GitHub (Apr 4, 2020): @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!

claunia commented

@grave0x commented on GitHub (May 1, 2020):

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

@grave0x commented on GitHub (May 1, 2020): 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

claunia commented

@matthew4850 commented on GitHub (Jun 22, 2020):

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.

@matthew4850 commented on GitHub (Jun 22, 2020): > EDIT: looks like `linux sudo` has always been `vulnerable` in this way. (I've only tested using WSL) > ![image](https://user-images.githubusercontent.com/3901474/72544102-8310f380-3865-11ea-96b1-0ce206f952ea.png) 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.

claunia commented

@DHowett commented on GitHub (Jun 22, 2020):

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

@DHowett commented on GitHub (Jun 22, 2020): I'm more concerned about [whatever X11 allows](https://www.kitploit.com/2018/08/rootstealer-x11-trick-to-inject.html) than "i can write to a tty device" (which only impacts the output stream)

claunia commented

@darealshinji commented on GitHub (Feb 14, 2021):

@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

@darealshinji commented on GitHub (Feb 14, 2021): @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`

claunia commented

@sylveon commented on GitHub (May 28, 2021):

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.

@sylveon commented on GitHub (May 28, 2021): 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.

claunia commented

@zadjii-msft commented on GitHub (May 28, 2021):

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

@zadjii-msft commented on GitHub (May 28, 2021): @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!

claunia commented

@sylveon commented on GitHub (May 28, 2021):

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

@sylveon commented on GitHub (May 28, 2021): 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 ;)

claunia commented