Terminal: [问题] 配置 Windows 终端配置文件以始终启动提升

那没有。 我认为我们不打算支持混合提升和未提升的选项卡，因为它有点安全漏洞。

是的，我知道sudo是一回事，但我们已经与安全团队就为 Windows 创建sudo进行了很多讨论。 主要问题是由于任何未提升的进程都可以将击键发送到任何其他未提升的窗口。

如果您在未提升的窗口中运行提升的命令行，则不受信任的不良行为者可以通过驱动运行提升的命令行的未提升的窗口来执行特权提升攻击。

（作为链接相关线程的问题，#146）

编辑（2020 年 2 月 14 日）
好的，所以这个评论并没有很好地老化。 最初，_no_ 计划支持这一点，因为它不适用于我们拥有的单个HWND 。 我们正在努力设计一个_可能_在未来支持这一点的解决方案，但我们不能承诺任何事情，直到我们确定我们可以提出一个适当安全的解决方案，以确保较低特权的进程不能驱动更高权限的终端。

似乎有道理。 我认为有一些类似#576（在跳转列表中以管理员身份打开）的组合，也许某种热键来启动终端的管理员会话可以解决我在这里的大部分痛苦。

在单个窗口中打开一个标准和提升的终端但单独的选项卡怎么样？

@mdtauk我认为不幸的是属于同一类别。 由于所有选项卡都在同一个 HWND 下，因此需要提升根 HWND 以防止未提升的应用程序驱动窗口。

从安全的角度来看（忽略 Windows 终端的设计、单根 HWND 等），与在当前 UX 中运行一个提升的 PowerShell 实例和一个非提升的实例相比，终端运行混合高度选项卡的“安全性”有多低? 控制台应用程序托管在终端选项卡中的事实对我没有影响......

在类似的说明中：即使我打开一个远程 PS 会话，我现在可能在远程服务器上拥有非提升窗口现在可以驱动的管理员权限，如何让非提升窗口更安全。 对我来说，这似乎比获得本地管理员访问权限要糟糕得多，所以我认为以管理员身份运行选项卡与远程 / SSH 进入其他服务器没有任何不同。 在这两种情况下，我都需要对我的系统感到足够舒服才能做到这一点。 这是“我已经够大了，我了解风险”的事情。

每当我尝试使用管理员帐户运行终端应用程序时，右键单击 -> 以管理员身份运行，UAC 会弹出两次并出现错误提示：
“Windows 找不到 (path\WindowsTerminal.exe) 确保您键入了 ...”。

该路径存在并且该应用程序对于构建该应用程序的非管理员用户可以正常工作，但其他管理员用户无法运行它。
如果我登录到管理员用户，则终端应用程序不会出现在设置或开始菜单中，就好像它从未安装在系统上一样。

有没有办法构建应用程序以便为所有用户安装？ 还是项目的根目录必须位于非用户特定的目录中？

@

每当我尝试使用管理员帐户运行终端应用程序时，右键单击 -> 以管理员身份运行，UAC 会弹出两次并出现错误提示：
“Windows 找不到 (path\WindowsTerminal.exe) 确保您键入了 ...”。

该路径存在并且该应用程序对于构建该应用程序的非管理员用户可以正常工作，但其他管理员用户无法运行它。
如果我登录到管理员用户，则终端应用程序不会出现在设置或开始菜单中，就好像它从未安装在系统上一样。

有没有办法构建应用程序以便为所有用户安装？ 还是项目的根目录必须位于非用户特定的目录中？

我也看到了同样的问题。

Windows 版本 18922.1000

是的，因此以管理员或其他用户身份运行商店应用程序不起作用（顺便说一句）。 我们中的许多人都作为普通的非提升帐户登录（到 PC）。 我们以管理员身份运行 powershell/cmd/etc 来执行某些任务。

如果最终的选择是将此应用程序部署为 Windows 商店，那么如果没有某种方式打开提升的选项卡，它对我来说毫无用处。 我的 2 美分。

“无用”可能有点苛刻，但我们确实需要一种方法来将新终端用于非提升和提升的控制台应用程序/shell。 对我来说，最好的 UX 是支持在同一个 Windows 终端实例中混合使用提升和非提升选项卡。 不太可取：支持零到多个（通常是一个）提升的实例（每个都有一对多的选项卡）以及零到多个（通常是一个）非提升的实例。

ConEmu 能够在同一窗口中混合提升和非提升选项卡。 不能在这里做这样的事情吗？

我们可以让一个提升的终端启动非提升的标签吗？ 我仍然需要启动提升但我可以打开一个“受保护”的新标签。

如果我们想要非常特定于 Windows 并忽略可能最终看到终端的其他平台，也许使用 Windows 容器或虚拟化进程可以帮助一些人解决这个痛点。 我个人对当前的解决方案很好，但是从安全的角度来看，让控制台应用程序默认作为一个独立的进程运行并不是什么坏主意。

至少对我来说，一个窗口中的混合海拔是必须的。
可以在设置中切换的可选功能吗？

@pratnala使用ConEmu 时，它只是_looks_ 好像它正在这样做，但它根本没有真正这样做。 提升和未提升的“选项卡”只是两个完全独立、隔离的根窗口/进程的视图。 它通过抓取窗口的内容以及代理/代理提升助手等来做到这一点。 当然，这在技术上是可行的，但 ConEmu 所做的实际上有点不安全。 第三方程序这样做并让人们通过下载 ConEmu 选择承担风险是一回事，但微软通过自己这样做来正式认可这一点是另一回事。 如果我想把我的前门钥匙藏在门垫下面，那很好——这是我冒的愚蠢风险。 但是，如果您购买的每一扇门都在门垫下面放了一套钥匙呢？

但是请看，我使用 C++（以及 C#、PowerShell、Ruby、Python、GoLang，几乎所有我喜欢的东西）进行开发。我安装了 ConEmu 和 TakeCommand，以及 mingw。 我知道跑步时拿剪刀的方法。

PowerShell _is_ 一个安全漏洞。 一个非常有用的自动化工具，允许各种意外访问。 而且我们所要求的（混合模式）肯定比替代方案（全部提升）更安全。确实，这个（终端）是高级用户的电动工具，他们中的大多数人可能非常了解安全形势......并且理解务实的妥协。

零信任仅在它不会使人衰弱时才有效。

@robomac如果我们能说服安全团队（他们曾多次告诉我们不要冒险接近混合海拔高度），只有知道如何正确握剪刀而不与他们一起跑步的人才会_使用_这个项目，我们可能会这样做。 我不知道我自己是否相信。 原因如下：

同样，如果终端运行在混合高度（从中等 IL 主机到高 IL 客户端），它仍然可以强制接收以该用户身份运行的其他任何东西的输入。 即使键盘后面的人是圣人并且只提升了她需要提升的十秒钟，_在她的用户帐户下运行的任何应用程序都可以冒充管理员而无需额外的提升提示_。 甚至可能完全未被发现。

@DHowett-MSFT 我感谢您的回复。 您假设我们允许恶意进程以任何方式运行。 我们限制了“最佳实践”口头禅的权限，我们每天早上都用朝下的狗姿势做，但是如果你真的担心几个小时，甚至，提升终端访问会让你处于危险_在你自己的系统上你正在开发_ ...

1. 你不应该运行终端和
2. 您应该擦拭并重新开始。

我承认（计算机）病毒研究人员不应该在向量路径中冒险……但即使在早期，我们也在虚拟机中对它们进行沙盒处理。 但是“终端”不适合您不精通的亲戚； 这是一个电动工具。

有一种处理风险的标准方法。 由浏览器世界带给您。 当你进入高级旗帜时，你会收到一个大致的警告，“这里是龙”。 （我认为正是在 Pale Moon 中......这是严重的硬核安全浏览器。）添加（非 UAC，附加）警告，但让用户决定。

另一个问题：终端的两个不同会话，一个提升，一个不提升，是否会按预期运行？ 或者两者都是任何会话的载体？

我不反对人们应该能够选择这样的事情。 ：微笑：

两个不同的会话

哦，是的，这在今天绝对可以工作——而不是一个向量（提升的向量在世界的 High-IL 一侧完全运行，不能由任何其他 Medium-IL 进程驱动）

今天应该绝对有效

本着同样的精神，不能 2 个选项卡在不同的进程中运行，从而在同一个窗口中启用混合提升吗？

@DHowett-MSFT 那么为什么不能在总体应用程序中托管两个不同的会话呢？ 真的不难做到。

我想我首先理解提升控制台应用程序的安全隐患，但我无法理解为什么在 Windows 终端中拥有两种类型的选项卡（提升和非提升）会比 Windows 支持的_更具风险_对于年龄，即并排运行高架和非高架 CMD / PowerShell 的。 有人可以对此有所了解吗？

@robomac
[1] 当您使用传统窗口句柄 _hosting 传统 windows_ 时，这是微不足道的。 这在 conemu 案例或选项卡式外壳案例中非常有效，您可以在提升会话中接管窗口并在非提升会话中的窗口下重新设置它的父级。

当您这样做时，我将在 [2] 中谈到一些安全功能。 正因为如此，你可以养它，但你不能真正强迫它做任何事情。

不过有一个问题。 终端不是作为可重新父窗口的集合而构建的。 例如，它没有运行控制台主机并将其窗口移动到选项卡中。 它旨在支持“连接”——可以读写文本的东西。 它是比窗口低级的基元。 我们意识到我们方法的错误，并认为 UNIX 模型一直都是正确的，管道、文本和流是_它所在的位置。_

鉴于我们使用 Xaml 岛来托管现代 UI 并将 DirectX 表面拼接到其中，无论如何我们都远远超出了标准窗口句柄的世界。 Xaml 岛完全组合成一个 HWND，很像 Chrome 和 Firefox 以及 DirectX/OpenGL/SDL 游戏的范围。 我们没有可以在一个进程（提升）中运行并托管在另一个（非提升）而不是上述“连接”的组件。

现在，明显的后续问题是_“为什么不能在非提升连接旁边的选项卡中设置一个提升连接？”_ 这是@sba923应该阅读的地方（:smile:)。 我可能会介绍一些你（@robomac）已经知道的事情。

[2] 当您在同一个窗口站的同一个桌面上有两个窗口时，它们可以相互通信。 我可以通过WScript.Shell SendKeys将键盘输入发送到 shell 可以看到的任何窗口。

运行一个进程提升_服务器_该连接。 外壳看不到升高的窗口。 与 shell 具有相同完整性级别的其他程序无法看到提升的窗口。 即使它有它的窗口句柄，它也不能真正与之交互。 这也是为什么如果记事本在提升运行时您不能从资源管理器拖放到记事本中的原因。 只有另一个提升的进程可以与另一个提升的窗口交互。

该“安全”功能（您可以随意称呼它，它可能曾一度打算成为一种安全功能）仅存在于少数会话全局对象类型中。 窗户就是其中之一。 管道并不是其中之一。

因此，破坏这种安全性是微不足道的。 以终端为例。 如果我们启动一个提升的连接并将其托管在一个_non-elevated_ 窗口中，我们会突然创建一个通过该安全边界的管道。 另一端提升的东西不是窗口，它只是一个文本模式的应用程序。 它立即执行非提升主机的投标。

任何可以_控制_非高架主机（如WScript.Shell::SendKeys ）的人_也_通过高程边界获得即时管道。 突然间，系统上的任何中等完整性应用程序都可以控制高完整性进程。 这可能是你的浏览器，或者安装了 NPM 的left-pad包的比特币矿工，或者任何数量的东西。

这是一个小风险，但它_is_风险。

为了用户的方便，其他平台已经接受了这种风险。 他们这样做并没有错，但我认为微软在“为用户方便而接受风险”之类的事情上获得的“通行证”较少。 Windows 9x 是一场彻底的安全灾难，有限的用户帐户和提升提示以及窗口管理的内核级安全性是解决这些问题的答案。 它们不是可以轻易松开的锁。

@DHowett-MSFT 非常感谢您的澄清。 我认为我们必须习惯并排运行一个提升的 Windows 终端实例和一个非提升的实例，就像我们现在使用控制台应用程序所做的那样。

迷人。 谢谢你。 终端更像是一个连接渲染器而不是一个窗口确实是有意义的。 这是否给已经相当关注管道/连接的 PowerShell 提供了对以前在窗口控制台中的任何额外控制？

单独的终端会话是否完全相互隔离？

只要有迹象表明我正在参加高级别会议，我就会完全满意。 比如“管理员：\ 我现在很想念那个很糟糕的东西。

？？？

“以不同的用户身份运行”是所有 Windows 管理员都需要的东西！ 如果可用，这将非常有帮助。 最好的选择是在每个配置文件的配置中都有一个标志。

BTW，说到窗口隔离，我引用最新的 ctfmon 漏洞报告

明显的攻击是非特权用户将命令注入管理员的控制台会话，或者在用户登录时读取密码。即使是沙盒化的 AppContainer 进程也可以执行相同的攻击。

@ecki这是一个相当令人不安的消息。 我敢肯定，在那之后，塔维斯今晚会去参加派对。

@DHDHowett-MSFT
正如这里的许多人所写的那样，如果新终端不能以“以不同用户身份运行”选项启动，那么对于大量用户来说，它不是很有用，而且它与微软的“Active Directory 管理层模型”不兼容例如，如果您有一个具有默认权限的 AD 用户，并在域控制器上使用 Adminuser 运行 PS 脚本。

我用我当前登录的用户启动终端的情况并不多……所以我问你，这个终端的用例是什么？ Ping，nslookup 等，.. 如果这是你的意图，那么你为什么要在这一切上投入这么多工作？

使用“以管理员身份运行”您有一些有效点，但为什么其他控制台（如（PS6/7））仍然支持这些功能，如果它不安全？

我一直认为新的终端应用程序将取代所有单独的 cmd/PS/... 窗口，但它似乎在许多现实世界的场景中不可用。 这有点可悲tbh...

@Fisico您的经验并不普遍，我鼓励您在要求某人证明他们的项目存在的合理性时考虑这一点。

对于您关于“以不同用户身份运行”不存在/不工作的总体观点：这是我们试图解除的平台限制。 我们不支持它不是出于恶意或无能。

至于为什么其他控制台应用程序_do_ 支持它，当它们这样做时并不是不安全的，因为它们特别没有在同一个窗口中托管不同的海拔高度。 这是这里的核心问题。 因为它们托管在具有独立窗口的独立进程中，所以它们不受跨完整性级别操作的限制。

@DHowett-MSFT
对不起，如果我的帖子冒犯了你，这不是我的意图，我投入了太多情感。
我认为终端是一个好主意并且具有很大的潜力，我很高兴您正在与社区一起开发它以充分利用它。

在这一点上，什么是实施什么不是实施有很多混乱。
整个应用程序的“以管理员身份运行”目前正在运行，这会留下来吗？

据我了解，每个选项卡/配置文件的“以管理员身份运行”不是您想要实现的。 我认为这对我们大多数人来说都可以。

“以不同用户身份运行”是不可能的，因为 Windows 不支持应用程序，您/我们必须等到 Windows 支持它？ 如果是这样，我们说的是年吗？

每个选项卡/配置文件的“以不同用户身份运行”也是您不想实现的吗？

@DHDHowett-MSFT
正如这里的许多人所写，如果新终端无法以“以不同用户身份运行”选项启动
比对于大量用户来说它不是很实用，......我一直认为新的终端应用程序会
替换所有单独的 cmd/PS/… 窗口，但它似乎在许多现实世界场景中不可用。 这有点可悲tbh...

我不同意。 与我们之前的相比，这是一个巨大的进步。 不幸的是，由于缺乏更细粒度的方法，我们大多数人可能已经养成了提升 shell 的习惯……我们仍然可以。 我们不能_混合_它们......但我们从来没有这样做过。 说真的，在我去过的最后三个公司中，开发人员 Wiki 已经在提升的 VS 提示符下进行了所有构建/测试。 我们通过实时扫描、积极主动的防火墙来实现安全，并且知道我们的开发人员很少搞砸。 _non-developers_ 从不提升，因为（1）我们不能信任他们，（2）他们不需要。

因此，我对这个新航站楼表示赞赏。 它并不完美，但 Take Command / TCC 也不是。 至少这是标准的。

@DHDHowett-MSFT
正如这里的许多人所写，如果新终端无法以“以不同用户身份运行”选项启动
比对于大量用户来说它不是很实用，......我一直认为新的终端应用程序会
替换所有单独的 cmd/PS/… 窗口，但它似乎在许多现实世界场景中不可用。 这有点可悲tbh...

我不同意。 与我们之前的相比，这是一个巨大的进步。 不幸的是，由于缺乏更细粒度的方法，我们大多数人可能已经养成了提升 shell 的习惯……我们仍然可以。 我们不能_混合_它们......但我们从来没有这样做过。 说真的，在我去过的最后三个公司中，开发人员 Wiki 已经在提升的 VS 提示符下进行了所有构建/测试。 我们通过实时扫描、积极主动的防火墙来实现安全，并且知道我们的开发人员很少搞砸。 _non-developers_ 从不提升，因为（1）我们不能信任他们，（2）他们不需要。

因此，我对这个新航站楼表示赞赏。 它并不完美，但 Take Command / TCC 也不是。 至少这是标准的。

提升！= 以不同的用户身份运行。
我更多地与其他 AD 用户一起运行 PowerShell，然后与我自己的用户一起运行。
我同意你经常以管理员身份运行 cmd 或 PS，即使你不必这样做，但在很多情况下你必须以管理员身份运行它。 大多数系统管理员任务需要管理员权限或具有某种特权的不同用户。
当然，如果您需要在用户上下文中运行 cmd，那就没问题了。

我了解“提升！= 以不同的用户身份运行”。 我只是不相信“以不同的用户身份运行”几乎像您声称的那样普遍。

我了解“提升！= 以不同的用户身份运行”。 我只是不相信“以不同的用户身份运行”几乎像您声称的那样普遍。

如果您与 Microsoft 世界有关，那么您绝对需要它。
例如，使用域管理员权限登录 Windows 机器并不是最好的主意。
使用具有域管理员权限或其他一些权限的用户运行 PS 脚本是很常见的。

@Fisico为什么不使用New-PSSession命令呢？

需要对服务进行某种特定提升的自动化脚本通常需要“以不同用户身份运行”。 这是否适用于终端是另一回事。 您始终可以使用runas命令在 CMD 或 PS 会话中更改一次登录。 这不会改变选项卡的提升状态，因为它使用的是您的常规用户的底层登录。 此外，您使用任务计划程序或 cron 作业运行的任何脚本都不需要终端来运行，除非您使用它来获得正常控制台会话中不存在的功能。 如果是这种情况，使用作为后台进程启动的终端运行该脚本的参数将是解决方案。

因此，选项卡的混合高度不是必需的。 我们有一个解决方法，很容易将您需要的特定 runas 命令复制到一个 txt 文件中，您可以将其复制/粘贴到终端中，然后填写您的密码（您永远不应该将密码保存到任何未加密的内容中）。

@SamuelEnglard
我不想连接到远程主机来运行脚本。

@WSLUser是的，它是使用 runas 的一个选项，但是以其他用户身份简单地运行终端或 PS 要方便得多。 我不明白为什么这应该是一个问题。

@Fisico New-PSSession不需要连接到远程计算机，请参阅第二个第一个语法条目。

@SamuelEnglard
我不想连接到远程主机来运行脚本。

@WSLUser是的，它是使用 runas 的一个选项，但是以其他用户身份简单地运行终端或 PS 要方便得多。 我不明白为什么这应该是一个问题。

用户将 PowerShell 固定到任务栏并右键单击以管理员身份运行或在某些环境中以 RunAs OtherUser 身份运行是非常标准的操作，因为需要提升的帐户才能运行和企业级脚本。 要说终端不可能，就像利用 PSLockDown 并强制 RunAs Admin 仅加载 shell 或 VSCode 的环境
恕我直言

如果您确实需要以其他用户身份运行选项卡，则可以有一个在开始时运行New-PSSession -Credential | Enter-PSSession的配置文件。

免责声明：我对因此而损坏的计算机不承担任何责任。

如果您确实需要以其他用户身份运行选项卡，则可以有一个在开始时运行New-PSSession -Credential | Enter-PSSession的配置文件。

>免责声明：我对因此而损坏的计算机不承担任何责任。

当然，或者可以重新考虑站在这里的“安全性”。 再次，我将 PowerShell 固定到我的任务栏，从那里我可以启动 PowerShell 非提升； 我可以右键单击它并选择“以管理员身份运行”，如果在公司环境中我可以右键单击该图标，然后 Shift-右键单击“Windows PowerShell”并选择“以不同用户身份运行”以启动 PowerShell使用备用凭据。 没有会话，没有 RDP'ing 到另一个主机来获得这些信用。

当然，或者可以重新考虑站在这里的“安全性”。 再次，我将 PowerShell 固定到我的任务栏，从那里我可以启动 PowerShell 非提升； 我可以右键单击它并选择“以管理员身份运行”，如果在公司环境中我可以右键单击该图标，然后 Shift-右键单击“Windows PowerShell”并选择“以不同用户身份运行”以启动 PowerShell使用备用凭据。 没有会话，没有 RDP'ing 到另一个主机来获得这些信用。

是的，我也可以使用 Windows 终端来做到这一点。 同意。 我看不出这对那些想要混合以不同用户（或不同高度）运行的选项卡的人有什么帮助。

除了“混合标签”之外，我只想澄清一下，由于 Windows Store 应用程序的设计，您不能使用（已发布的预览版）Windows Terminal 执行此操作。 您只能以安装该应用程序并以同一用户身份登录的用户身份运行。

我想要的只是能够做我今天所做的事情，以普通用户身份登录 PC 并运行提升的 shell。 如果 Windows 终端按原样发布，对我来说用处不大。

很好的一点。 Windows 终端的私有（非存储）版本不存在此限制。

除了“混合标签”之外，我只想澄清一下，由于 Windows Store 应用程序的设计，您不能使用（已发布的预览版）Windows Terminal 执行此操作。 您只能以安装该应用程序并以同一用户身份登录的用户身份运行。

我想要的只是能够做我今天所做的事情，以普通用户身份登录 PC 并运行提升的 shell。 如果 Windows 终端按原样发布，对我来说用处不大。

我刚刚打开了 2 个 Windows 终端商店版本的实例 - 一个提升了，一个没有。 所以我不知道为什么它不适合你。

好的，我必须相信您是 PC 上的本地管理员。 说清楚，也许我应该澄清一下。 我从来都不是我工作站的本地管理员。 因此，当我转到“以管理员身份运行”时，系统会提示我输入用户/密码。

我使用的“管理员”帐户与我正常的恶意软件/电子邮件阅读帐户不同。 所以从技术上讲，我所做的是以不同的用户身份运行。 这是 Windows 应用商店应用程序限制。 解决方案（也许他们会这样做）是将它作为一个没有这些限制的 Windows 组件发布。

* [紧急] 我已经找到了解决这个问题的方法！ * *

按照本指南
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
您可以将 Windows 应用程序文件夹设为您自己的文件夹！

完成此操作后，您可以找到Microsoft.WindowsTerminal._blahblahYourVersion_文件夹。 进入后，找到WindowsTerminal.exe如下所示

找到它后，创建此文件的快捷方式并将其放置在您想要的任何位置。 完成后，将其设置为以管理员身份运行。 您可以通过右键单击并转到_属性>高级>以管理员身份运行_之后单击确定，一切就绪！

我个人需要这个，因为我使用任务栏中的快捷方式，这样我就可以点击 _Windows+1_ 以管理员身份启动它。 浏览我的开始菜单以正确运行它并不是很长的路要走。

您也可以解压缩我们放在发布页面上的包。 它只是一个 ZIP 文件。 请注意，我们_不官方支持_解包执行！

但这仍然意味着没有_supported_方式来运行提升！ 我认为这是一个必须具备的功能。

确实，我的立场是正确的。

_is_缺少的是任务栏快捷方式右键菜单中的“以管理员身份运行”条目。

昨天在一次聚会上与几个人交谈，一些人说他们主要使用 Windows+X 启动 powershell，并且希望在那里有终端/终端作为管理员。

很好的一点！

这正是我的观点！ 这是从任务栏运行它的解决方案
具有管理员权限！

2019 年 8 月 25 日，星期日，凌晨 1:08 Stéphane BARIZIEN [email protected]
写道：

很好的一点！

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/microsoft/terminal/issues/632?email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CNA6Q#issuecomment-524603514 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
.

确实，我的立场是正确的。

_is_缺少的是任务栏快捷方式右键菜单中的“以管理员身份运行”条目。

在任务栏中右键单击两次。 一次在图标上使上下文菜单出现，然后在应用程序名称上第二次。 例如“Windows 终端（预览版）”并选择“以管理员身份运行”

我感到困惑。

脸红。

羞愧。

我怎么没想到这个？

无论如何，感谢您与我们所有人分享！

让我们从另一端来看问题......
Windows 允许非提升进程控制其他非提升进程、发送击键、捕获其 UI 等……但阻止非提升进程对提升进程的窗口执行此操作。
Windows 终端还设计用于通过 ssh、PowerShell 远程处理等方式管理远程服务器……
这意味着 Windows 终端一旦用于管理就会成为一个安全漏洞，因为本地恶意软件可能会等待 Windows 终端会话来监视用户正在做什么，并且一旦它检测到远程 shell，就尝试注入命令以使用管理员权限感染服务器。

阻止 Windows 终端以管理员身份运行似乎根本不是一种安全改进，因为以管理员身份运行它会保护用户免受非提升进程劫持其远程 shell 会话的影响。 每当用户使用可在本地或远程提供提升命令提示符的工具时，都应向用户推荐以管理员身份运行它。

关于 Windows 的 sudo，不运行 sshd 服务然后从非提升的 shell 连接到 localhost 会出现相同的安全问题吗？

这意味着 Windows 终端一旦用于管理就会成为一个安全漏洞，因为本地恶意软件可能会等待 Windows 终端会话来监视用户正在做什么，并且一旦它检测到远程 shell，就尝试注入命令以使用管理员权限感染服务器。

虽然远程系统确实可能被感染（假设远程进程具有管理员权限），但这并不意味着我们也应该让它感染本地系统。

阻止 Windows 终端以管理员身份运行似乎根本不是一种安全改进，因为以管理员身份运行它会保护用户免受非提升进程劫持其远程 shell 会话的影响。 每当用户使用可在本地或远程提供提升命令提示符的工具时，都应向用户推荐以管理员身份运行它。

现在没有什么能阻止您以管理员权限运行 Windows 终端。 手头的问题是混合提升和非提升选项卡。

@SamuelEnglard回应。

另外，我们正在尝试做的是避免添加_新_安全漏洞。 原始控制台在远程服务器管理方面存在同样的问题。 不幸的是，我们对此无能为力。 进行远程服务器管理的用户总是在提升他们的控制台/终端运行，这将给他们一些额外的安全性（尽管我不是安全专家，我不会将该声明解释为建议）

关于这个问题的进展想法：尝试以提升的方式运行整个 _app_，如果成功，在每个“打开”按钮旁边添加一个带有 UAC 盾牌图标的按钮，并添加一个前缀键绑定以打开提升的选项卡： Ctrl移E。 （我检查过，这是未绑定的。）它仅适用于下一个打开的选项卡。

无论如何，打开的选项卡在其常规图标之前有一个 UAC 图标，并以管理员身份运行。 （请记住，程序无法再发送此密钥。我们以管理员身份运行该应用程序。）

应用程序应该尝试自动提升，如果失败，则正常运行，并忽略整个线程。

确实，我的立场是正确的。
_is_缺少的是任务栏快捷方式右键菜单中的“以管理员身份运行”条目。

在任务栏中右键单击两次。 一次在图标上使上下文菜单出现，然后在应用程序名称上第二次。 例如“Windows 终端（预览版）”并选择“以管理员身份运行”

刚刚注意到在这种情况下 UAC 提示符显示“未知程序”。

如果你问我，那真是出乎意料...

@sba923那是 #2289 ：微笑：

@DHowett-MSFT 感谢您提供信息； 很高兴知道（已经）跟踪。

我能想到的最佳答案是可以选择拥有必须提升的配置文件，如果当前窗口未提升，则使用该配置文件启动一个新的提升实例。 （想想私人浏览会话是如何工作的）

非常好的主意

我用这种方式在 Win+X 菜单中添加终端：
使用目标创建一个新的快捷方式：
C:\Windows\explorer.exe shell:appsFolder\Microsoft.WindowsTerminal_xxxxxxxxxxxx!App
编辑：
抱歉，如果您想以管理员身份运行应用程序，这将不起作用。
相反，您可以使用 nircmd 并创建一个快捷方式
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

（“Microsoft.WindowsTerminal_xxxxxxxxxxxx”的正确路径可以通过PS命令“Get-appxpackage *WindowsTerminal*”找到，使用PackageFamilyName中的条目）

此快捷方式可用于通过简单的双击以管理员权限启动终端，并且可以使用 WinXEditor 将其添加到 Win+X 菜单中。
注意：终端也必须安装在管理员帐户中。

是以管理员身份加载每个配置文件还是仅加载某些配置文件的想法？ 理想情况下，我希望通过个人资料拥有它。 也许一个属性是“runas”帐户而另一个属性是“iselevated”？

正如本线程中详细讨论的那样，您不能在同一 Windows 终端实例中混合使用提升和非提升，并且不会添加。

确实，我的立场是正确的。
_is_缺少的是任务栏快捷方式右键菜单中的“以管理员身份运行”条目。

在任务栏中右键单击两次。 一次在图标上使上下文菜单出现，然后在应用程序名称上第二次。 例如“Windows 终端（预览版）”并选择“以管理员身份运行”

FWIW，我刚刚测试了shift-and-right-click，它立即给出了“以管理员身份运行”选项——只比我之前选择的两次右键单击选项快一点。

嘿，伙计们，你忘了 UAC 了吗？ 应用程序无法单击安全桌面中的内容。

FWIW，我刚刚测试了shift-and-right-click，它立即给出了“以管理员身份运行”选项——只比我之前选择的两次右键单击选项快一点。

您也可以 ctrl + shift + 左键单击图标以立即调出 UAC。

太棒了，非常感谢！ 我们必须记住多少捷径？ ;-)

对于您关于“以不同用户身份运行”不存在/不工作的总体观点：这是我们试图解除的平台限制。 我们不支持它不是出于恶意或无能。

至于为什么其他控制台应用程序_do_ 支持它，当它们这样做时并不是不安全的，因为它们特别没有在同一个窗口中托管不同的海拔高度。 这是这里的核心问题。 因为它们托管在具有独立窗口的独立进程中，所以它们不受跨完整性级别操作的限制。

绝对希望在某个时候以不同的用户身份运行。 虽然不是我日常活动的大部分，但一些 powershell cmdlet 需要提升（我与不同的用户一起运行，认为是受保护的用户管理员）。

这不是世界末日，但不得不退回到传统的 shell 肯定会很烦人。

时间，我猜！

使用提升的 Windows 终端绝对没有问题/限制，因此无需坚持使用“旧 shell”（或更准确地说：旧控制台主机）。

只是你不能在同一个实例中（不同的选项卡）混合提升和非提升。

使用提升的 Windows 终端绝对没有问题/限制，因此无需坚持使用“旧 shell”（或更准确地说：旧控制台主机）。

只是你不能在同一个实例中（不同的选项卡）混合提升和非提升。

我想我可能误解了上述内容，但是在与我正在阅读的内容完全不同的用户上下文下运行终端存在平台限制。

我想我可能误解了上述内容，但是在与我正在阅读的内容完全不同的用户上下文下运行终端存在平台限制。

是的，在这一点上，这个线程已经遍地开花。 我不是工作站的管理员，所以“以管理员身份运行”只会提示我输入“提升的信誉”。

我们可能应该简单地有一个关于该用例的新线程。

需要明确的是，我的意思（我认为很多“管理员”需要）是能够以普通用户身份登录我们的工作站。 然后以提升的用户身份运行“某些 shell”，就像说域管理员一样来执行 AD 工作。

对或错，这是我们中的一些人所做和需要的。 以该用户的身份从商店安装控制台和设计巧妙的快捷方式的所有技巧对我来说并不真正奏效。

是的，我可以通过多种方式做到这一点，也许我应该将其中一些活动限制在受保护的工作站上，但实际上，作为普通用户，我通常不需要 shell。

IMVHO 混淆源于这样一个事实，即人们（保持 Vista 之前的习惯很难消亡）或多或少可以互换使用术语“提升”和“作为另一个 [域] [管理员] 用户”。

以其他用户身份运行与提升权限运行不同。

1. 此线程中的一些人在以管理员用户身份登录时需要运行具有提升的 Windows 终端工作负载。

2. 其他一些人在以普通（或非域管理员）用户身份登录时需要以另一个管理员用户身份运行 Windows 终端工作负载，通常具有提升权限。

3. 还可以考虑以下情况：人们以普通用户 A 的身份登录并希望以用户 B 的身份运行 Windows 终端工作负载而无需提升权限。

在 #2 和 #3 中，基于 Windows 应用商店的部署使故事更加复杂，因为 Windows 终端不会以登录用户身份运行，而“应用商店应用程序”是为该用户部署的。

希望我正确理解情况。 如果我这样做，我希望这能澄清一点。

你完全正确。

仅供参考，那个确切的问题，当您登录的帐户不是系统上的本地管理员时，无法提升（“以管理员身份运行”，而不是以另一个管理用户身份运行，“以不同用户身份运行”），根据最佳实践），在另一个问题中简要介绍了： https ://github.com/microsoft/terminal/issues/1538。 结束时解释说它是 Windows 问题，而不是终端问题，因为它似乎是商店应用程序的限制。

无需争论这是否应该作为 MSI 安装而不是使用商店发布，我使用的那个线程中有一个解决方法； 以您的管理员帐户短暂登录，从商店安装应用程序，然后再次注销。 以管理员身份运行然后为我的普通用户帐户工作（直到下一次更新，当它必须再次完成时）。

是的，应该有可用的 MSI。 我的新雇主不允许（公共）商店安装，所以我能够使用 Windows 终端的唯一方法是从源代码构建......

失望地看到您无法“以管理员身份”运行 Windows 终端而不会出现错误，然后不得不实施解决方法。 我想说很多公司对身份实施特权分离方法（ICT员工拥有特权和非特权帐户）。 因此，通过根据@sba923的建议提供可选的 MSI 部署来满足这一要求将是一种巧妙的方法，直到此时商店捆绑的应用程序可以应对特权分离？

这是一个预览版，甚至不是 1.0 版本...

我觉得这个话题在这一点上已经讨论得很好，但是有一个观点我还没有理解：为什么我们不能为这个应用程序创建一个 Windows 快捷方式？ 这是“始终以管理员身份启动”的典型解决方法——典型的解决方法是创建一个快捷方式并将快捷方式更改为默认使用提升的访问权限。

有人可以向我解释为什么我们不能创建此应用程序的快捷方式吗？ 这可能与 Windows 的内部工作原理有关，而不是 Terminal 的内部工作原理，但如果我不直接询问，我觉得我们是在拐弯抹角。

谢谢。

我将 nircmd 与许多其他常用工具一起保存在我的 c:\utils 文件夹中。
我添加了一个如下所示的配置文件：

        {
            "name": "Admin Terminal",
            "startingDirectory": "c:\\utils\\",
            "commandline": "cmd.exe /q /c nircmd elevate \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
            "hidden": false
        },

它会提出一个 UAC 提升请求，然后打开一个 Windows 终端的管理实例。 目前这是一个不错的解决方法。

老实说，我可以将会话标记为提升并在新窗口中打开它们。

我来这里是为了寻找一个简洁的解决方案，但由于它似乎不存在，所以我将分享我的 hacky-ish 解决方案。 我添加了一个用于运行 powershell 提升的配置文件：

{
...
  "commandline" : "powershell.exe -Command \"Start-Process PowerShell -Verb RunAs\"",
...
}

它会在一个单独的窗口中弹出，但它可以完成工作。

我觉得这个话题在这一点上已经讨论得很好，但是有一个观点我还没有理解：为什么我们不能为这个应用程序创建一个 Windows 快捷方式？ 这是“始终以管理员身份启动”的典型解决方法——典型的解决方法是创建一个快捷方式并将快捷方式更改为默认使用提升的访问权限。

有人可以向我解释为什么我们不能创建此应用程序的快捷方式吗？ 这可能与 Windows 的内部工作原理有关，而不是 Terminal 的内部工作原理，但如果我不直接询问，我觉得我们是在拐弯抹角。

谢谢。

@aaronsteers ，你说得对，它更多的是关于 Windows，而不是关于终端。 这里的主要问题是我们作为“现代应用程序包”分发和安装。 与本机应用程序相比，它们有许多限制和意外限制，但对于终端来说这是必要的，因为它也是使用“现代 Windows API”(WinRT) 组件最简单的方法。 这几乎总是让团队中的每个人都感到非常沮丧。 ：微笑：

我们正试图将这种挫败感和社区的挫败感转化为平台的进步。 不过，我会道歉，在 Windows 中这种变化并不快！

@DHowett我真的很想理解，因为我 2/3 喜欢终端，但它并没有做一些我习惯于使用 TakeCommand 或 ConEmu 等的基础知识。

我不能在各个选项卡中混合高程。 如果我理解，那是因为您是一种不同类型的应用程序并且没有真正托管外壳？

在三种环境（cmd、PowerShell、wsl bash）中的任何一种中，回滚缓冲区都不会清除。它在我的普通 shell 中会清除。 再次，因为它的托管方式？

如果有一个更易于访问的上下文或下拉菜单，那就太好了。 例如，要清除该回滚，考虑到即使是控制台转义技巧也对我不起作用。

环境的集成以及它对 WSL Linux shell 的支持程度非常好。 但是由于海拔和回滚问题，它消耗了很多可用性，所以我很少使用它。

@robomac @DHowett-MSFT在这里发表了一篇很棒的文章，解释了为什么我们不能在同一个未提升的窗口中混合提升和未提升的选项卡。

tl;dr 是：如果我们允许用户从未提升的终端窗口连接到提升的命令行，那么就会产生一个巨大的安全漏洞，其他未提升的应用程序可以通过终端窗口有效地驱动提升的进程。

我不知道 ConEmu 如何降低这种风险，如果他们这样做的话。 完全有可能这是 conemu 创建的一个安全漏洞，我们不愿意将其作为 Windows 终端的一部分进行发布。

您剩下的问题都是在此 repo 中其他地方跟踪的所有问题，我建议搜索它们以单独跟踪它们的进度。 我们更愿意将此线程保留在“标签的混合提升”/“具有启动提升的配置文件”的单一主题上

关于主题：我确实想尝试“提升”配置文件的“启动另一个实例提升”路线。 如果用户体验不是太差，那么这是一条可能的前进路线，至少作为一种选择。

ConEmu 不会降低这种风险。 他们将风险转嫁给用户。 （我什至不确定他们是否记录了这种风险。）

关于“启动另一个提升的实例”主题：我不介意这种行为，只要它可以为这些选项卡使用相同的提升终端实例，并且每次调用“提升”配置文件时都不会启动新实例。

在我看来，这个安全漏洞的“巨大”有点被夸大了。 在一个人的计算机上安装恶意软件并等待升级的机会是不正常的，因此为了安全而牺牲便利性是不对的。

另一方面，如果最终目标是让 WT 作为默认终端与 Windows 一起提供，那将大大增加攻击面。 但同样，在这种情况下，我个人会通过使用不太可能成为此类攻击的目标并提供所需便利的不受欢迎的替代方案来降低风险（假设检测终端中是否存在提升的选项卡并不简单特定于终端）。

其中一些是 tl;dr 对我来说，但如果你拿走并转储包，你可以在沙盒之外运行 wt，这意味着提升，并在不同的用户工作时运行而不会出现问题。 我曾在 ignite 与 MSFT 谈过此事，并被告知提交拉取请求，但我的 VS 技能相当薄弱。 很简单的做法是正确签名（必须使用我自己的内部 pki 执行此操作，以便我可以在 applocker 上运行）并将其放入 MSI 或 MSIX 可分发格式。 这里或那里有一个奇怪的错误，可能特定于以这种方式运行它，但总的来说它工作得非常好。 现在我只有一个功能，可以从基于商店的版本中提取、签名和替换/更新基于程序文件的版本。

我理解将提升的选项卡“插入”到未提升的进程中的风险，但是否有可能反过来呢？
对于人们来说，这是多么需要这个，让终端本身也以高架方式运行并允许启动非高架标签？
当然，这还有其他缺点，但对我来说（我认为对其他人也是如此）它们是可以接受的。
（当然，这可能是“有趣的”，因为终端是一个 Windows 商店应用程序，不确定是否有效）

附言。 抱歉重新打开此问题（如果其他人已经提出该建议并且我“阅读”了该建议）。

感谢@EmTschi ，我制作了简单且 100% 方便的解决方案
它使用上下文菜单并且行为与 PowerShell 7 非常相似
https://github.com/nt4f04uNd/wt-contextmenu
在那里你可以找到如何实现它的指南和所有需要的文件

感谢您的提示，我稍后会尝试。
目前，我正在桌面上使用两个快捷方式，它们映射到键 Ctrl+Alt+T 和 Ctrl+Alt+Shift+T 用于提升的终端，它也可以作为一种解决方法，但是......不太好因为它可能是并且远离像 sudo 这样的东西。

@

每当我尝试使用管理员帐户运行终端应用程序时，右键单击 -> 以管理员身份运行，UAC 会弹出两次并出现错误提示：
“Windows 找不到 (path\WindowsTerminal.exe) 确保您键入了 ...”。
该路径存在并且该应用程序对于构建该应用程序的非管理员用户可以正常工作，但其他管理员用户无法运行它。
如果我登录到管理员用户，则终端应用程序不会出现在设置或开始菜单中，就好像它从未安装在系统上一样。
有没有办法构建应用程序以便为所有用户安装？ 还是项目的根目录必须位于非用户特定的目录中？

我也看到了同样的问题。

Windows 版本 18922.1000

刚刚安装在 Win10 更新 1909 上，尝试以管理员身份运行时遇到同样的问题

这里同样的问题。 现在不能使用 windows 终端，因为我总是需要运行 docker，然后我总是需要在终端中成为管理员......

对于任何想要它的人，我都有一个 hack-around 解决方案：

1. 从发布页面下载 msixbundle
2. 解压缩，在那里找到适合您平台的 msix（通常是 x64 的）
3. 将其解压缩到某个文件夹中
4. 将该文件夹复制到任何你喜欢的地方并运行 WindowsTerminal.exe 提升或者你喜欢

很多这种失败似乎来自将其作为商店应用程序的便利性。 #1386 上对此进行了讨论，有人提到可能使用 Scoop 进行安装，它可以自动执行上述提取过程。

如果以下人员被视为一等公民，那就太好了：

1. 便携式安装（zip 文件——即使配置还不是便携式的，因为它在用完 Windows 商店安装区域时位于 AppData\Local 下）
2. 一个常规的旧 .exe 安装程序（或者，如果必须的话，.msi），适用于不想要应用商店或使用应用商店安装程序的人

正如 Scoop 自动化所证明的那样，从当前的构建过程中实现两者都不是那么棘手。 现在 Windows 终端变得非常好，我希望能够像使用任何其他终端一样使用它。

虽然我们正在这样做：除非存在 API 不兼容，否则最好选择在 Windows 10 的早期版本（我的雇主在 1809/ RS5，并且从商店安装被阻止）。

@sba923如果我们不依赖仅存在于 1903 年的 API，我们将不需要 1903。

当然......是我的猜测😜

将不得不游说在全公司范围内升级，可能会碰壁……

这太愚蠢了。

让我们为 windows 的命令提示符、powershell 和 bash 制作一个新的统一终端。
我可以以管理员身份运行 cmd.exe 吗？
不。

猜猜我只会保留我的 cmd.exe 和 powershell 图标预设，然后无限期地在我的任务栏上以管理员身份运行。

像这样的愚蠢的东西就是为什么我的主要工作机器仍然是 Macbook。

这太愚蠢了。

让我们为 windows 的命令提示符、powershell 和 bash 制作一个新的统一终端。
我可以以管理员身份运行 cmd.exe 吗？
不。

猜猜我只会保留我的 cmd.exe 和 powershell 图标预设，然后无限期地在我的任务栏上以管理员身份运行。

像这样的愚蠢的东西就是为什么我的主要工作机器仍然是 Macbook。

我同意这种情况。 我想要一个包含我需要的所有终端选项卡的单个 Windows 终端窗口，其中每个终端选项卡可以是多个已安装的终端主机之一，并且可以提升或不提升。

看起来这种混合高度功能确实受到了技术设计决定的阻碍，即在单个 HWND 句柄上托管所有选项卡。

1）你能以管理员身份运行新终端吗？ 是的（根据您安装/启动它的方式，这样做会出现问题，但不希望它不起作用）。 （如果您不知道如何执行此操作，请参阅上面的多个帖子以了解如何执行此操作。

2）你可以让一个标签提升而另一个不是吗？ 没有。 请参阅https://github.com/microsoft/terminal/issues/632#issuecomment -519375707 了解原因。

请大家记住这个问题是关于混合高程标签的吗？！？ 如果您想启动整个过程提升并且无法打开一个新问题。

@DHowett-MSFT 我们可以将此问题重命名为关于混合高程选项卡吗？

无论处理与否，提升的终端或选项卡都应该有某种指示器。 现在，如果我以管理员身份运行启动新终端，则无法轻易注意到我的 cmd 选项卡与下一个窗口中的选项卡相比具有更高的访问权限。

在@SamuelEnglard的评论之后编辑：显然我匆忙选择了cmd作为一个坏例子。 是的， cmd在选项卡标题中显示“管理员：”。 但是我的默认选项卡上的 WSL Ubuntu bash 会覆盖其选项卡标题中可能存在的任何内容。 我猜bash不知道（甚至不关心）Windows 终端的提升，因此在从bash更新标题时无法使用该信息（当然有sudo情况，但这是另一回事）。

在终端的profiles.json中，有
"showTabsInTitlebar": false
但是使用此设置，终端的标题栏不会发出海拔信号。

@janilahti提升 CMD 选项卡看起来不像
为你？

如果没有人想使用您的工具，安全性是一个有争议的问题......

你应该只为在 cmd.exe 和 powershell 中工作的 windows 创建一个 sudo 命令。 这样可以省去将两者都设置为以管理员身份运行的快捷方式的麻烦。

仅供参考，我写了一个sudo for windows ，称为gsudo ： https ://github.com/gerarddog/gsudo

它支持提升cmd / powershell / pwsh命令或整个 shell。 它易于安装和使用，应该类似于原始的 *nix sudo。 在野外还有其他sudo实现，但恕我直言， gsudo是最通用且易于使用的。

例如，您可以使用它来创建调用gsudo cmd / gsudo pwsh或gsudo WhateverShell以启动提升的选项卡的 WT 配置文件。 安装gsudo并添加 WT 配置文件：

    {
      "hidden": false,
      "name": "PowerShell Core elevated",
      "commandline": "gsudo.exe pwsh"
    }

它是一个 C# 客户端-服务器应用程序，在未提升时充当客户端，并将自身提升为服务器。 两个实例都通过安全命名管道进行通信。 其他 Windows sudo 大多类似于弹出新窗口的 PowerShell 'runas' 脚本，但作为一个完整的应用程序，我可以添加更多功能。

我已经阅读了该线程，并讨论了 sudo 命令的安全性，并提出了一些有效的观点。 我已经采取了我能想到的所有安全措施，并且我愿意（并计划）引入更多安全措施。 此时，它应该是安全/不安全的，就好像您打开远程管理 PS 会话或从非提升控制台执行ssh root@server一样。 （例如，容易受到击键或屏幕报废的影响，如果我错了，请纠正我，但我的理解是 *nix sudo 也容易受到这种方式的影响）。 还有凭据缓存，它可以减少 5 分钟会话期间 UAC 弹出窗口的数量（受 *nix sudo 启发），这显然是一种攻击媒介，可以通过配置禁用。 对于那些担心安全性的人，我计划通过简单的命令或通过企业组策略/注册表设置添加一种非常简单的方法来加强它（通过禁用凭据缓存等功能）。

此评论中提出的一个有趣的观点是，微软无法承受“为用户方便而接受风险”。 如果这是 MS 的最终决定，那么至少这看起来是一个不错的（功能齐全的）解决方法，并且欢迎所有关于如何提高安全性的反馈/问题或想法。

不能是我必须安装的不受官方支持的东西。 杀死任何在公司环境中使用它的能力。

然后@hparadiz ，您将不得不等到具有新安全设计的新版本 Windows 发布，该设计允许官方 sudo（或混合高度选项卡）而没有安全风险。 看来这不会很快发生。 你最好的办法是等到整个 WT 可以以管理员身份启动，在 #4217 中跟踪，可能会更早发布。

从博客中找到了一个不错的 hack：

http://nuts4.net/post/windows-terminal-run-as-admin

@gerardog你有gsudo的勺子桶吗？ 还是在已知之一中？ 我目前在一个 linux 机器上，所以无法检查。

@fluffynuts它在独家新闻的主要仓库中。 所以只需“舀安装 gsudo”。 https://github.com/gerarddog/gsudo中还列出了其他安装方法。 但是，让我们继续讨论 WT 主题。 😉

开放式问题：如果混合提升和未提升的选项卡存在安全风险，那么ConEmu中是否存在这种风险？ 因为它可以做到这一点。 或者 ConEmu 是否以与终端不同的方式实现该功能？ 更广泛地说，我会注意到这里请求的许多功能（在这个线程和其他线程中）已经存在于其他终端中，ConEmu 只是一个例子，所以当终端开发人员建议这些功能要么永远不会实现，要么不会实现很长一段时间，您只是在暗示我们不应该使用终端。

如果我们不依赖仅存在于 1903 年的 API，我们将不需要 1903。

@DHowett-MSFT 是否有任何关于这些 API 以及它们为何必要的公共文档？ 因为作为一个外部观察者，当我看到这个决定和使用 UWP 的决定时，我看不到附加值。 我只是看到添加许多企业用户认为是基本功能的障碍。

@dadpolice有关 ComEmu 的功能，请参阅https://github.com/microsoft/terminal/issues/632#issuecomment -518888895。

根据微软的说法，我认为“UAC 不是安全屏障”？ 它在 Vista 中被视为一个。 然后我们被告知它不是一个问题，任何类似的问题在 Windows 7 中都是一个笑话。现在它今天又是一个？

在这种情况下，您可能需要查看文件资源管理器和 UAC 白名单的设计。 :)

还是仅仅取决于它是否是借口走捷径来设计普通开发人员不允许做的事情（文件资源管理器）或不实现基本功能（在这种情况下）？

没有实现基本功能（在这种情况下）？

我想说清楚 - 我们不是试图_不_实现这个功能。 这当然是我们_想要_实现的一个重要特性。 这是我现在每天都会遇到的事情 - 有第二个升高的窗口是_okay_，但它不是_good_。

我们需要一段时间才能设计出适当安全的解决方案，然后还要进行工程工作以实际实施它。 这甚至是我们这周用白板写了一段时间的东西。

@zadjii-msft

[...]
我认为我们不打算支持混合提升和未提升的选项卡，因为它有点安全漏洞。
[...]

（作为链接相关线程的问题，#146）

奇怪的是，人们认为该功能不会实施。 讽刺标志

@kort3x “没有计划”（也就是我们不承诺）和不想做他们能做的事情找到实现它的方法是有区别的。

正如@zadjii-msft 所说：

我们需要一段时间才能设计出适当安全的解决方案，然后还要进行工程工作以实际实施它。 这甚至是我们这周用白板写了一段时间的东西。

只要他们没有安全的解决方案，他们就不会计划（也就是承诺）支持混合海拔选项卡。 我愿意成为第二个确实有安全解决方案的人，他们会将其添加到计划中（尽管我不能保证任何事情）。

根据微软的说法，我认为“UAC 不是安全屏障”？ 它在 Vista 中被视为一个。 然后我们被告知它不是一个问题，任何类似的问题在 Windows 7 中都是一个笑话。现在它今天又是一个？

据我了解，如果配置为“始终通知”，这是一个安全屏障，否则不是。

好吧，这令人失望。 我喜欢终端（这说明了很多，因为我通常非常迷恋非 MS 工具），但无法顺利提升是我在这个操作系统上做更多工作的真正障碍。

哈哈，好吧，我明白这有多令人困惑。 我最初是在我们第一次宣布之后几天写的，当时还没有计划。 经过几个月的讨论，我当然已经意识到这可能是可能的，而且需要付出更多的努力。 我会去更新评论以反映这一点。 @SamuelEnglard是对的，但很难 _commit_ 这样做，直到我们_知道_可以正确地做到这一点。

这令人鼓舞。 是否可以将这种热情延伸到其他团队，因此#3581实际上可以修复？

如果首先允许选项卡是不同的进程（类似于 chrome 管理它的方式），那就太好了，因为这样我就不必在很好地分组它们之后重新启动所有选项卡，只是为了在一个单一的环境中获得更新的环境cmd选项卡...
一旦 Windows 终端只是一个管理器，它就可以在非提升模式下运行，同时仍保持提升的命令提示符。 那样就好了。 （好吧，在持有非高架终端的同时让 wt 高架运行对我来说也可以）

@ rapus95 从技术上讲，这些选项卡是，因为“控制台”是一个不同的过程。 Windows 终端已经只是一个管理器

编辑（2020 年 2 月 14 日）
好的，所以这个评论并没有很好地老化。 最初，_no_ 计划支持这一点，因为它不适用于我们拥有的单个HWND 。 我们正在努力设计一个_可能_在未来支持这一点的解决方案，但我们不能承诺任何事情，直到我们确定我们可以提出一个适当安全的解决方案，以确保较低特权的进程不能驱动更高权限的终端。

除了其他几点，这就是我仍在使用ConEmu的主要原因。 我敢打赌我会的。
https://conemu.github.io/ @Maximus5

这太愚蠢了。

让我们为 windows 的命令提示符、powershell 和 bash 制作一个新的统一终端。
我可以以管理员身份运行 cmd.exe 吗？
不。

像这样的愚蠢的东西就是为什么我的主要工作机器仍然是 Macbook。

@hparadiz看看 ConEmu :-D 在一个窗口中将多个 Shell 作为选项卡运行没有问题； 甚至在非提升会话之外运行提升的 Powershell 和 cmd.exe 会话。

@tmeckel我们确定 conemu 没有终端团队担心的安全漏洞吗？ 用户经常选择不太安全的软件，因为它可以做他们想做的事，但后果自负。

@drdamour @tmeckel确实如此。 我在上面问了同样的问题，它在另一个线程中得到了回答： https ://github.com/microsoft/terminal/issues/632#issuecomment -518888895

到目前为止，我一直对 Terminal 持批评态度，但公平地说，ConEmu 和 ConsoleZ 以及其他类似工具已经存在。 Microsoft 简单地复制它们没有什么价值，但以安全的方式重新创建这些功能具有很大的价值。 也就是说，我仍然认为将终端模拟器构建为仅限商店的 UWP 应用程序是非常愚蠢的，尤其是现在微软似乎正在远离 UWP（例如，新的 Edge 是 Win32 应用程序）。

也就是说，我仍然认为将终端模拟器构建为仅限商店的 UWP 应用程序是非常愚蠢的，尤其是现在微软似乎正在远离 UWP（例如，新的 Edge 是 Win32 应用程序）。

需要明确的是，终端不是仅限商店的（这里有 .msix 可用），也不是 UWP 应用程序。 它是一个使用 UWP XAML 作为其 UI 框架的 Win32 应用程序。

@ rapus95 从技术上讲，这些选项卡是，因为“控制台”是一个不同的过程。 Windows 终端已经只是一个管理器

那么，为什么没有为新的 cmd 实例更新环境呢？ 我总是需要打开一个新的 Windows 终端，这在某种意义上会降低拥有多个选项卡的整体可用性......

@ rapus95虽然我不肯定（我必须深入研究代码），但我很确定每个子流程都是以其父环境而不是新环境启动的。

对于终端经理来说，这似乎没有意义🤔

@rapus95这实际上是我们在这里跟踪的一个错误：#1125

需要明确的是，终端不是仅限商店的（这里有 .msix 可用），也不是 UWP 应用程序。 它是一个使用 UWP XAML 作为其 UI 框架的 Win32 应用程序。

这听起来像是带有额外步骤的 UWP。 不管是什么原因造成的，所以我不能右键单击终端并以不同的用户身份运行它，就像使用任何普通的 Win32 应用程序一样，这是一个奇怪的选择。

它不是 UWP 应用程序，也不是商店专用应用程序。
恰好其中一种分发方法是 Store，它需要 UWP 包。
只有那些使用商店安装它的人才能Right click -> Run As Admin 。
卸载并使用msix或通过scoop

卸载并使用msix或通过scoop

或chocolatey 。

@gerardog我没有说以管理员身份运行，我说以不同用户身份运行。

Shift + Right Click不适合你吗？

（请注意我使用scoop安装）

不，我已经使用 msix 包进行了安装，但该选项不存在。

我安装为巧克力，也没有以管理员身份运行

需要明确的是，终端不是仅限商店的（这里有 .msix 可用），也不是 UWP 应用程序。 它是一个使用 UWP XAML 作为其 UI 框架的 Win32 应用程序。

这听起来像是带有额外步骤的 UWP。 不管是什么原因造成的，所以我不能右键单击终端并以不同的用户身份运行它，就像使用任何普通的 Win32 应用程序一样，这是一个奇怪的选择。

同样在这里，我已经尝试了 msix 和商店应用程序。 我仍然没有“以其他用户身份运行”选项。

将所有提升的选项卡背景颜色设为红色怎么样，这样很明显它已经提升了？

我宁愿有这个可配置的：背景颜色，标签标题......

https://github.com/gerarddog/gsudo可以很好地作为临时解决方案

也许实现类似wt elevated的东西，它打开一个新的提升窗口，当前 shell 具有相同的环境。
编辑：或 #3158 但作为新窗口并提升

我不明白你为什么不复制 Linux 的做法。

根据我的理解或 Linux 世界（如果我错了，请纠正我），即使您键入 su 或 sudo 并执行命令作为终端应用程序（gnome-terminal、mate-terminal ...）也不需要提升根用户。 终端应用程序的唯一任务是在提升或不提升的不同进程（bash、ksh...）中运行 shell，并重定向 shell 输入和输出，以便我们可以与 shell 交互。

如果您在 linux 终端中键入“su”或以“sudo”开头的命令，它不会打开另一个窗口。

@gabsoftware即使在 Linux 上，我也不确定它的安全性。 在 Linux 中也可以向 X 窗口发送击键，我的猜测是，即使正在运行的终端使用 sudo 或 su 提升，也可以向在 X 窗口中运行的终端客户端发送击键。 甚至可以将击键发送到提升的 X 窗口，但我真的不确定。

需要明确的是，终端不是仅限商店的（这里有 .msix 可用），也不是 UWP 应用程序。 它是一个使用 UWP XAML 作为其 UI 框架的 Win32 应用程序。

这听起来像是带有额外步骤的 UWP。 不管是什么原因造成的，所以我不能右键单击终端并以不同的用户身份运行它，就像使用任何普通的 Win32 应用程序一样，这是一个奇怪的选择。

同样在这里，我已经尝试了 msix 和商店应用程序。 我仍然没有“以其他用户身份运行”选项。

我不能通过右键单击开始菜单中的磁贴来“以其他用户身份运行”，但如果我右键单击 WindowsTerminal.exe 则可以

@gabsoftware即使在 Linux 上，我也不确定它的安全性。 在 Linux 中也可以向 X 窗口发送击键，我的猜测是，即使正在运行的终端使用 sudo 或 su 提升，也可以向在 X 窗口中运行的终端客户端发送击键。 甚至可以将击键发送到提升的 X 窗口，但我真的不确定。

我已经做了一些实验，现在我很确定这在 Linux 上的不安全性。 我不是安全专家，所以我不确定这（任何人？）的含义。 事实证明，将击键发送到刚刚运行 sudo 并且无需输入密码即可对新的 sudo 命令开放的 X 窗口非常容易。 博客在这里，对不起可耻的插件......

我的结论是，除非有办法禁止将击键发送到混合高度窗口，否则这应该只作为愿意接受风险的用户的选项来实施（大胖警告标志等）。

附带说明一下，Windows 的屏幕键盘如何将击键发送到提升的窗口？

我已经发布gsudo v0.7 并且与这个线程相关：

编辑：对于上下文： gsudo是 Windows 的 sudo，并允许在当前控制台中提升一个简单的命令或 shell。 当从 WT 中的 Cmd/Pwsh 调用时，它会提升选项卡。 此外，您可以编辑您的配置文件，将其命名为“Elevated Powershell”并将您的命令更改为gsudo Powershell和瞧，您得到了一个提升的选项卡配置文件。 见这里。

但是由于 gsudo 或任何适用于 windows 的 sudo 跳过了 UAC 隔离，因此它被标记为“不安全”。 下面是一个更复杂的解决方法，它允许您在保持安全性的同时进行选项卡的混合提升。 /结束编辑

gsudo现在可以启动具有任何完整性级别的应用程序。 例如，我们可以使用MediumPlus 完整性级别启动Windows Terminal ，这意味着“半提升”模式：无管理员权限，但与其他常规（中等完整性）进程隔离，无法访问。 （将出现一个 UAC 弹出窗口）

因此，第一步应该是始终使用以下命令启动 WT： gsudo -i MediumPlus WT
（您可以更改您的 WT 快捷方式）。 这可以保护 WT 免受恶意进程、屏幕抓取、sendkeys、dll 注入等的侵害。
（编辑：如果它不工作使用： gsudo -n -i MediumPlus cmd /c cmd /c start wt ）

然后，您可以在 WT 中安全地使用gsudo来提升命令，甚至可以使用以下命令创建提升的配置文件：profiles.json 中的"commandline": "gsudo cmd.exe"

我的结论是，除非有办法禁止将击键发送到混合高度窗口......这应该只作为愿意接受风险的用户的选项来实施（大胖警告标志等）。

完成了，完成了。 （我已向 gsudo 添加了安全警告）。

此外，由于我了解到如果用户从常规/中等完整性进程调用 gsudo ，那么 gsudo 的凭据缓存（显示较少 UAC 弹出窗口的功能）将无法得到完全保护......所以，现在凭据缓存必须通过gsudo cache on/off或gsudo config cachemode auto显式启用。

事实证明"Changing your WT shortcut"一点也不简单：给定 MSIX/AppStore 模型，您遇到了 #4217 和 #4459。

以下 powershell 脚本解决了这些问题，以在桌面上创建 Windows 终端快捷方式并将其与 Ctrl+Alt+T 热键关联：

$shortcutPath = [Environment]::GetFolderPath("Desktop") + "\Windows Terminal Isolated.lnk"

# Use this if installed via Scoop. 
$wtPath = "$home\scoop\apps\windows-terminal\current\WindowsTerminal.exe"

# Use this if installed via Chocolatey or Ms Store
$wtPath = (Get-Command 'wt.exe').Path

$cmdPath = (Get-Command 'cmd.exe').Path
$gsudoPath = (Get-Command 'gsudo.exe').Path

$WshShell = New-Object -comObject WScript.Shell
$link = $WshShell.CreateShortcut($shortcutPath)
$link.TargetPath = $gsudoPath
$link.Arguments = "-n -i MediumPlus cmd /c cmd /c start $wtPath"

#Optional, set global Keyboard Hotkey
$link.Hotkey="Alt+Ctrl+T"

# Optional, download icon.
$icoPath = [IO.Path]::GetDirectoryName($wtPath) + "\wt.ico"
Invoke-RestMethod -Method Get -Uri "https://raw.githubusercontent.com/microsoft/terminal/master/res/terminal.ico" -OutFile $icoPath
$link.IconLocation="$icoPath,0"

$link.Save()

一旦您将 WT 作为 MediumPlus（即 Ctrl+Alt+T）启动，您就可以使用 gsudo （如上文所述）（https://github.com/microsoft/terminal/issues/632#issuecomment-613751789）来提升命令在什么AFAIK应该是安全的。

我的解决方法是使用Luke Samson的_Sudo for Windows_ 。 配置文件配置是：
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
使用该配置文件启动新选项卡时，会弹出 UAC，然后您最终会进入提升的 Powershell Core。 也适用于任何其他终端。
"commandline": "powershell.exe -Command sudo.ps1 powershell.exe",
"commandline": "powershell.exe -Command sudo.ps1 cmd.exe",
如果你不使用scoop ，我相信这个概念可以独立提取和使用。 在此处查看源代码： https ://github.com/lukesampson/psutils/blob/master/sudo.ps1

我正在使用 schtasks 解决方法以管理员身份运行 Windows 终端并绕过 UAC：

1. 启动任务计划程序。
2. 创建一个新任务。 给它一个名字并选中“以最高权限运行”复选框。
   

3. 在“操作”选项卡上，选择启动程序： wt

4. 在“设置”选项卡上，确保选中“允许按需运行任务”并取消选中“如果运行时间超过则停止任务”复选框。

5. 通过右键单击桌面创建快捷方式并选择新建 -> 快捷方式并键入schtasks.exe /run /TN "{task name}"
   
6. （可选）更改快捷方式图标并将其拖动到任务栏。

看起来我将不得不坚持使用 cmder 直到这个问题得到解决。

既然据说有计划的暗示，我们可以得到文件吗
更新为不再说没有当前计划？

https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md#starting -a-new-powershell-tab-with-admin-privilege

@drdamour一旦有了_is_ 计划，我很想删除该部分。 不过，目前只有一个计划来研究制定计划的方法。 一旦有了真正的计划，并且我们可以安全地做到这一点，我将删除该部分。

@KMoraz描述的方法目前非常适合作为一种解决方法。 感谢您发布此信息。

大家好，

在我昨天发现这个之前，我一直在使用ConsoleZ 。
ConsoleZ 有一些功能，一个是使用 UAC 以管理员身份启动一个新选项卡（它会弹出 UAC 的对话框）。
我发现它非常有用，因为您无需使用键盘即可打开新的提升选项卡。

如果它是配置文件配置中的配置怎么办？ 这就是它在 ConsoleZ 中的完成方式。

大家好，

我发现了另一种快捷方式解决方法，它很简单，非常适合那些在以管理员身份运行任何东西时必须输入本地管理员凭据的人。

此链接解释，但需要 wt.exe 参考的完整路径：
http://nuts4.net/post/windows-terminal-run-as-admin

我的完整快捷方式字符串是： C:\Windows\System32\cmd.exe /c start /b C:\Users\myUserName\AppData\Local\Microsoft\WindowsApps\wt.exe

2020 年 5 月 21 日更新：
以上用于在版本 1.0.1401.0 之前工作。

也看到这个新问题： https ://github.com/microsoft/terminal/issues/6013

现在，当您必须使用本地管理员帐户进行升级时，Crtl-Shift 单击也不起作用。

请参阅以下错误屏幕截图，我在被提示两次提升权限后得到：

有关信息，imho gsudo 非常适合这个，谢谢https://github.com/microsoft/terminal/issues/632#issuecomment -613751789

我的配置只有这个配置文件才能获得特权：

            {
                "name": "Admin Powershell",
                "commandline": "cmd.exe /c gsudo powershell.exe",
        "titleText": "Admin Powershell",
                "icon": "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png"
            },

对我来说，以管理员身份打开 Windows 终端的最简单方法是将其固定为任务栏上的第一项。 然后Win+Ctrl+Shift+1以管理员身份打开它

对我来说，以管理员身份打开 Windows 终端的最简单方法是将其固定为任务栏上的第一项。 然后Win+Ctrl+Shift+1以管理员身份打开它

确实非常方便，但这仅适用于管理员组成员的帐户。

如果您充当其他人的管理员，您将无法从他们的帐户以您的（管理员）用户身份运行 Windows 终端。

我认为最好设置一个选项卡以管理员身份运行 cmd 而不是所有内容。

我认为最好设置一个选项卡以管理员身份运行 cmd 而不是所有内容。

正如此处其他地方所解释的，这在当前设计中是不可能的。

是否有可用于以管理员身份运行的标志？ 然后我们可以为它创建一个快捷方式。

如果将 Windows 终端固定到任务栏，则可以使用 Ctrl+Shift+单击启动它_elevated_。

这将与右键单击图标，右键单击“Windows 终端”，然后单击“以管理员身份运行”相同。

注意：Windows 终端是一个商店应用程序，您不能以_另一个用户_的身份运行它。

我希望看到在 Windows 终端中具有“混合完整性级别选项卡”的能力，完整性级别作为每个配置文件中的一个选项。 这主要是为了方便我的正常系统管理员/devops 工作，以最大程度地减少工作流中断和上下文切换。

我找到了一个对我现在有用的简单替代方案。 这并没有解决其他用户在此处提出的所有方案。 它不依赖于第三方应用程序、快捷方式文件、组合键或计划任务。 它不需要识别 Windows 终端可执行文件的位置。 它只是在 Windows 终端配置文件列表中创建一个单独的条目，以启动第二个提升的 Windows 终端实例。 这会触发一次 UAC 提示。 我只在需要提升时才使用它。

结果是两个 Windows 终端。 一个中的任何东西都是标准的，另一个中的任何东西都是高尚的。 对我来说，这是可以接受的中断和上下文切换水平。 提升的 Windows 终端还在每个选项卡标题前加上“管理员：”，这可以很好地直观地确认差异。

编辑：我安装了 Powershell 7，

            "name" : "Launch Windows Terminal Elevated",
            "commandline" : "pwsh.exe -command Start-Process -Verb RunAs wt.exe"

@IarwainBen-adar，我似乎记得最近在新文档中看到您不能同时使用commandline项目和source项目。 如果没有source项目，它是否按预期工作？

我尝试了他的代码，甚至无法让新项目出现在拉取中
下菜单。

@shem-sargent 对此感到抱歉，我在这里删除了我的评论，因为无关的source声明确实是问题所在。 虽然，现在我的菜单项工作了，但不幸的是，我仍然无法启动提升的 Windows 终端实例——我遇到了问题 #3145，失败The file cannot be accessed by the system.

@IarwainBen-adar 抱歉，我无法重现 #3145。 否则，我会尝试进行故障排除。

固定到任务栏并shift+右键单击

干杯@LordFPL ，当然还有@gerardog ，我以前从未听说过gsudo（其他感兴趣的人可以使用https://github.com/gerardog/gsudo），但这让提升会话变得轻而易举。 谢谢！ 要么将其添加到设置文件中的配置文件对象，要么只使用sudo别名，就像在 Linux 系统上所做的那样。 完美的！

@zadjii-msft 我很抱歉，但我不完全明白这里的问题是什么。 Windows 支持令牌操作和模拟，这就是 runas 的工作方式，不是吗？ 使用来自@gerardog 的gsudo ，我可以拥有一个低（er）完整性 wt，同时托管一个高（er）完整性 shell，同时作为任何其他级别的完整性 shell，无论是 powershell、pwsh、cmd 还是任何 wsl shell。 从我有限的测试来看，没有一个低（er）完整性的 shell 可以调试到更高完整性的 shell。 将其作为内置终端，或者在操作系统级别更可取的功能，这里的障碍是什么？

@smokeintheshell https://github.com/microsoft/terminal/issues/632#issuecomment -519375707

低（er）完整性窗口_接收输入并将其直接汇集到高（er）完整性进程_打开该高（er）完整性进程，以由系统上的其他低（er）完整性事物控制。

这意味着潜在的恶意进程只需要在同一特权级别进行横向移动即可获得 EoP。

@smokeintheshell #632（评论）

低（er）完整性窗口_接收输入并将其直接汇集到高（er）完整性进程_打开该高（er）完整性进程，以由系统上的其他低（er）完整性事物控制。

这意味着潜在的恶意进程只需要在同一特权级别进行横向移动即可获得 EoP。

是的，我在线程开头阅读了该解释，但我不明白为什么它适用于 Linux，可能还有 Mac，但不适用于 Windows？ Windows 当前保护对提升进程的输入不受非提升进程的影响。 在这个问题或相关问题中，有人建议我们需要每个选项卡一个单独的进程。 我认为情况已经如此，因为每个选项卡都有自己的命令要执行（例如：pwsh.exe）。 是不是因为它们都是同一个 HWND 下同一个根进程的子进程？

如果我出现以下情况，Ubuntu 的终端是否会遇到与选项卡相同的问题：

• 打开su的标签
• 有一个标签，我已经用sudo提升了，并且不需要按照配置策略再次输入我的密码？

或者 Ubuntu 的架构是否以某种方式强化了跨进程输入注入攻击？

如果我出现以下情况，Ubuntu 的终端是否会遇到与选项卡相同的问题：

* have a tab with `su` open

* have a tab where I have elevated with `sudo` already and don't need to enter my PW again per configuration policy?

或者 Ubuntu 的架构是否以某种方式强化了跨进程输入注入攻击？

如果您在此处查看我的评论，我实际上已经在 Linux 上复制/利用了该问题。 su 和 sudo 都可能同样“脆弱”，因为您可以将击键发送到运行这些命令的完整性较低的窗口。 sudo 密码超时（不必在 15 分钟内在下一个 sudo 命令中输入您的密码），使这更加容易。 您可以通过禁用攻击所需的 X 扩展来强化 Ubuntu。 不确定这在 Wayland 环境中是否可行（攻击和/或强化）。

我完全理解不实施混合高度选项卡的决定，除非有某种方法可以禁用虚拟键盘和其他软件输入法。

我认为情况已经如此，因为每个选项卡都有自己的命令要执行（例如：pwsh.exe）。 是不是因为它们都是同一个 HWND 下同一个根进程的子进程？

@kbirger是的，每个选项卡都有单独的进程，但是您的所有鼠标和键盘输入仍会发送到 Windows 终端的窗口（完整性低），然后通过标准输入流路由到每个 shell 进程。 这就是所有 Windows 终端的键盘快捷键的工作方式。

我想知道是否可以检测输入是否是伪造的，例如使用GetCurrentInputMessageSource API。 除了官方示例之外，我找不到有关此 API 的太多信息，但从描述中它应该能够识别输入源（硬件/来自具有 uiAccess 的进程，主要是可访问性软件/来自没有 uiAccess 的进程，可能是恶意的）

为什么它适用于 Linux，可能还有 Mac，但不适用于 Windows？

我很确定这三个原因之一是微软将安全作为一项功能出售给其他大公司或政府。

关于为什么直到现在这可能还不是问题，我还想到了其他一些原因：

• 长期以来，由于种种原因（例如“黑客”不喜欢 Windows，“每个人”都在使用 Windows ^^），Windows 曾经是各种恶意软件的主要（≈唯一）目标。 它需要更好的安全性（保护升高的窗户），而其他人并不在意。
• 正如本期前面所解释的，恶意软件应该不可能轻松访问您在 Windows 上提升的控制台主机，因此很可能没有多少人在这个问题上进行过投资（我不是安全专家，所以我不知道如果有些人有）
• 除了尝试在您选择的操作系统中找到提升的命令提示符之外，恶意软件通常还有其他提升自身的方法
• 只有开发人员和系统管理员使用终端（这只会减少攻击的目标人群；政府和大公司仍然是一个问题）

现在，通过天真地引入该功能（正如我们所做的那样，我敢肯定😄），您将在某些 Windows 安装中引入一个新的（巨大的）缺陷。 随着开发的公开进行，您可以确定每个有需要的人都会意识到这个缺陷并开始针对它进行编码。
快速的对策是禁止 Windows 终端（现在可能还有所有其他终端模拟器，因为该漏洞是公开的），然后你就可以告别在任何类型的企业环境中使用 Windows 终端的梦想😟

不过，我仍然非常希望这个功能的安全版本能够看到曙光🤞

我知道了。 感谢您的解释！

附带说明一下，Windows 的屏幕键盘如何将击键发送到提升的窗口？

@mrwensveen AFAIK 有三种方法可以将输入发送到提升的窗口：

1. 提升自己。 但是，您仍然不能将输入发送到系统进程（例如任务管理器、UAC 对话框、登录屏幕）。
2. 注册 Windows 服务。 现在您的程序以 SYSTEM 身份运行，因此您可以做任何您想做的事情。 我见过一些远程访问程序这样做。
3. 声明uiAccess标志，对二进制文件进行数字签名，安装到当前用户不可写入的位置。 它是辅助软件的“后门”，允许它们读取/写入任何其他程序（包括系统进程），并显示在任何其他窗口（包括显示 UAC 弹出窗口和登录屏幕的安全桌面）之上，所有这些都无需运行提升。 请参阅https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview。

屏幕键盘 (osk.exe)、Narrator.exe（可能还有其他屏幕阅读器）都使用方法 3。

（显示带有uiAccess=true的 osk.exe 的嵌入式程序清单的屏幕截图）

看起来uiAccess标志也可以保护程序不被其他低完整性程序访问（尽管仍然运行未提升），也许我们可以使用这个“功能”来保护 WT？

@yume-chan 很酷，这很有趣，谢谢！ uiAccess程序是否允许向其他uiAccess程序发送击键？ 我们仍然希望 OSK 能够与 windows 终端交互，如果这意味着其他程序至少应该在允许将输入发送到 windows 终端之前进行签名，这是一个足够高的障碍吗？

是否允许 uiAccess 程序向其他 uiAccess 程序发送击键？

@mrwensveen是的，具有uiAccess权限的程序可以相互访问。

我更喜欢GetCurrentInputMessageSource API 方式（https://github.com/microsoft/terminal/issues/632#issuecomment-651114562），因为这不是uiAccess的预期用途。 同样使用 API，我们可能仍然允许低完整性程序将击键发送到未提升的选项卡，而不是提升的选项卡。

我在这里做了一点解决方法：

我已经安装了PowerToys ，它有一些很酷的功能。 其中之一是显示 windows 快捷方式，我发现当您按 Win + 数字时，它会在 windows 栏中打开与它出现在栏中的数字相对应的应用程序。

所以，我把终端放在栏中作为第一个图标
.

当我按 Win + 1 时，终端打开。

当我按 Win + Ctrl + Shift + 1 时，它会打开提升。

如果您想在提示符中获得显示 git 分支和 conda 环境的功能，并且如果它是提升的终端，则将用户显示为红色，我也会将我的终端配置和powershell 配置文件放在这里...

至少从 Windows 7 开始就已经存在。 这不是 PowerToys 的事情。

@Firehawke是的，我只是因为 PowerToys 而发现的……它不需要。

这是一个在 Windows Store 上运行并具有正确图标的提升配置文件：

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

编辑：感谢 @glooms 、 @shem-sargent 、 @LordFPL和@Firehawke为这个片段的不同组件。 由于此命令调用pwsh.exe ，看起来有些人遇到了 #4228（启动时出现0x80070002错误），这是由于 PATH 环境变量损坏或路径中名为powershell.exe的奇怪二进制文件pwsh.exe 。 @zurkz通过引用powershell.exe解决了这个问题，但我认为现在这不可靠。 #6684 解决了 Windows 终端的这个问题，你会在下面找到一个固定版本，遵循该解决方案，它根本不应该有这个问题。

这是一个在 Windows Store 上运行并具有正确图标的提升配置文件：

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@bb010g效果很好！ 谢谢你。

这是一个在 Windows Store 上运行并具有正确图标的提升配置文件：

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@bb010g ❤💯

这是一个在 Windows Store 上运行并具有正确图标的提升配置文件：

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@anyone原谅我的无知，这会被丢弃在 Windows Store 配置中吗？ 如果是这样，有人可以发布路径吗？ 如果不是，这个坏男孩应该住在哪里？

蒂亚！

@Kazamario
它位于配置文件部分的 Windows 终端 settings.json 文件中。

启动时会导致错误： 0x80070002 。 密码 7.1。

我将其更改为：

{
    "name": "Windows Terminal (elevated)",
    "commandline": "powershell.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

和 UAC 提示提升权限。

我将其更改为：

{
    "name": "Windows Terminal (elevated)",
    "commandline": "powershell.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

和 UAC 提示提升权限。

这对我很有效。 谢谢！

如果将 Windows 终端固定到“开始”，以下是如何启动提升的 Windows 终端。
https://github.com/farag2/Utilities/blob/master/Windows%20Terminal/Pin%20to%20Start.ps1

@narfanar看起来您遇到了 #4228，当 PATH 环境变量被弄乱或其他二进制文件在名为powershell.exe的路径中浮动时，Windows 终端在启动时会发出错误0x80070002 #$或pwsh.exe 。 我认为@zurkz的代码段并不能真正解决这个问题，因为它只是将潜在问题从pwsh.exe转移到powershell.exe 。 #6684 为 WT 修复了这个问题，所以这里有一个针对该解决方案调整的片段：

{
    "name": "Windows Terminal (elevated)",
    "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

console-z 做得很好

请注意，Cmder 具有此功能，非常有用。 希望看到它在 Windows 终端中实现。 即使它必须为“管理”选项卡或其他东西启动一个单独的窗口..

我的默认配置文件设置为 bash 而不是 powershell，我想保持这种状态。 上面的代码片段效果很好，但我希望能够让它启动一个加载了 powershell 配置文件的新提升终端。 我花了大约 3 个小时试图解决这个问题（不是 powershell 的忠实粉丝/对 powershell 有很多经验），但我想不通——请帮忙。 似乎有一些单引号、双引号、转义、空格、换行符的组合，这可能会使其工作，但我无法让 start-process 和 argumentlist 做我想做的事。 我把它归结为：

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
如果我自己运行它，这适用于 .ps1 文件，我会得到一个新的提升的 Windows 终端，并加载了 powershell 配置文件。 但它在settings.json的命令行参数中不起作用，无论我如何尝试修改它，显式调用argumentlist而不是使用cmd / c，各种形式的转义和引用用法等。

"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p \"Windows PowerShell\"'",
不起作用。 我能做的最好的就是让它推出一个我想要的奇怪的混合体。 我会加载一个“管理员：Ubuntu”窗口，它看起来像我的 bash 配置文件，但实际上正在运行 powershell。 错误的字体和一切。 如果我使用该窗口打开一个新的 powershell 选项卡，它将根据需要提升。 当它像这样时，我可以将任何我想要的垃圾放入配置文件加载的“Windows PowerShell”部分，我得到完全相同的行为，所以我知道它并没有真正尝试加载我正在传递的配置文件。

所以我在尝试以提升的方式运行它时遇到问题，我已经完成了上面列出的每个选项，我要么得到“找不到文件”错误，要么就是这个。

Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At line:1 char:1
+ Start-Process -Verb RunAs shell:appsFolder\\Microsoft.WindowsTerminal ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

还有其他人遇到问题或无法让它们正常运行吗？

我的默认配置文件设置为 bash 而不是 powershell，我想保持这种状态。

我也是。 我大部分时间都在运行 WSL，但时不时地我需要运行提升的 PS，我想在新 WT 的选项卡中执行它。

我也无法让任何示例工作 - 即使更正了我的文件路径。 我找到并安装了gsudo ，它可以提升当前选项卡，或者用作配置文件以在同一窗口中打开提升的选项卡。 我不确定上述解决方案是否在新窗口中开始（我在使用gsudo之前所做的一些尝试只会在新窗口中开始）。 它将打开一个 UAC 弹出窗口。

这是我正在使用的配置文件：

{
    // 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
}

我正在使用supressApplicationTitle以便选项卡标题不显示Administrator:因为它与Elevated冗余。

@ayfine如果https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 确实不适合您，您能否发送一份您在该配置中遇到的确切错误/意外行为的转录本？ （确保以尽可能小的步骤添加额外的配置，例如suppressApplicationTitle ，这样如果您的任何配置破坏了 WT，就可以更容易地判断它发生的地点和时间。）

如果此处的任何其他配置比您链接的配置稍远，那么有关这些配置如何破坏的详细信息也将不胜感激。

@bb010g我没有遇到任何错误消息 - 很抱歉我的回复没有更准确。 使用https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 时，我遇到了 Windows Terminal 加载我的 WSL Ubuntu shell（我的默认值）的问题。 我最初认为这意味着它无法正常工作，但我现在看到，在那个新窗口中，如果我启动一个新的（默认配置文件）Powershell 选项卡，它实际上已被提升。 无论如何，通过打开一个新窗口并必须在其中启动一个新选项卡，这并不比从我的开始菜单运行提升的进程更容易。 我在原始回复中描述的内容与我想象的确切行为一致。

@ayfine - 我复制了你的 gsudo 示例。 在对内置内容进行编码之前，这是一个足够好的解决方案。 谢谢。

@ayfine我尝试了 gsudo 的东西，但这是一次非常糟糕的体验。 任何类型的 TAB 完成似乎都会中断，并且似乎没有显示 Unicode（非 ASCII）字符。 我猜这是某种重定向输入和输出的过程，并且做得很糟糕。 我认为带有单独窗口的解决方案效果更好。

如果您在使用 gsudo 时遇到问题，请将它们报告给@gerardog而不是在此线程中。 此线程上的每条消息（包括此消息；对不起！）都会通过电子邮件发送数百名订阅者。

我将锁定该线程以进一步发表非维护者评论，因为我们已经到了进一步评论不会使讨论向前推进有意义的程度的地步。

如果您有此处未涵盖的问题，请提交新问题。