PowerShell 🚀 - 支持sudo<powershell cmdlet=""/>

哼！很有意思。但是，我认为实际行为符合预期。与Windows一样，我们没有sudo这样的命令。
但是，您可以使用“ sudo powershell”，然后执行remove foo.txt（使用“ sudo powershell”创建），然后在使用Remove-Item时可以正常工作。当然，在未提升权限的情况下将无法使用。

我只会在PowerShell中在Linux命令（“ sudo nautilus”）上使用“ sudo”。

:)

MaximoTrinidad 于 2017-02-28

即使在Windows上，具有与其他用户或提升用户身份一样运行cmdlet的功能以及可移植脚本中可能依赖的功能也将是不错的。为此可能需要一个RFC。

SteveL-MSFT 于 2017-03-01

👍64 ❤6

此功能对于解决＃3506很有用。

pcgeek86 于 2017-04-07

如果无法解决，这将成为阻碍我适应Linux的障碍。我们不允许sudo bash，并且同样无法执行sudo powershell。

我同意Maximo的观点，我们应该将sudo放到bash上，并使用sudo作为预期功能的支架，在powershell中制作一个新的cmdlet来进行提升。

pixelrebirth 于 2017-04-15

👍8

@dantraMSFT一直在对此进行调查，Dan您可以提供有关此方面最新想法的最新信息吗？

SteveL-MSFT 于 2017-04-15

👍1

@pixelrebirth能否提供您期望的更多详细信息？您是否希望通过等待，输出重定向或管道重定向来简单执行？
一些示例用法也将很有用。

dantraMSFT 于 2017-04-15

👍1

@dantraMSFT为了论证，我将像cmdlet一样调用新的sudo：调用提升
这就是sudo的工作原理，并且可以通过Powershell方式转换为Invoke-Elevated

$cred = Get-Credential
Invoke-Elevated -credential $cred -command {
        Get-ChildItem ./test | Remove-Item -force
} | Get-SomeCmdlet

在此示例中，脚本块中的所有内容都将提升执行，然后通过管道传递给NON提升的Get-SomeCmdlet
Cred可以是其他用户，也可以是您自己的高级用户（权限必须保留在某个位置，例如sudoers文件也称为白名单）

对于执行了Invoke-Elevated的实例，默认情况下应启用日志记录：
用户| 指令| DateTime或类似格式的日志记录

也许其中一些会在以后扩展或更改，但这将消除我的阻止因素

pixelrebirth 于 2017-04-15

👍9

它也应该像这样工作：

Get-ChildItem ./test | Invoke-Elevated -command {Remove-Item -force}
凭证是您当前的用户，它只要求输入密码...

在此示例中，Get-ChildItem为NON升高，而Remove-Item为升高

pixelrebirth 于 2017-04-15

我今天在社区电话上询问这一问题，但是我的妻子在解释这一挑战时受了伤，我错过了很多。您能在这里写下笔记，以便我将其转发给我的老板吗？

我会尽可能提供帮助，并在需要的地方施加压力。

pixelrebirth 于 2017-04-20

@pixelrebirth希望她还好！我们将在第二天或第二天记录通话记录，以便您随心所欲。

基本摘要是， @ dantraMSFT正在进行初步调查，以弄清楚如何以非骇客的方式进行此操作。今天，您可以从另一个Shell中sudo powershell -c "invoke-foo" ，但这显然是行不通的。

@dantraMSFT ：当您进行调查时，也许会发布一些状态以确保每个人都了解使用不同方法进行权衡的情况？

joeyaiello 于 2017-04-20

👍1

这看起来似乎很明显，但也许可以看一下sudo源代码，看看他们如何管理它-也许它需要一些底层编码。希望我对代码有更深的了解，对您有所帮助。

她还好，她在手术臀部上感觉到。感谢您对此的快速回复。我正在做一些黑客工作，如果我将它发布的话，我会在这里发布。

pixelrebirth 于 2017-04-20

👍2

@pixelrebirth作为参考，sudo使用setuid位，有关详细信息，请参见https://unix.stackexchange.com/a/80350/86669 。但是，将其设置在整个外壳上可能不是一个好主意。

J5lx 于 2017-04-24

必须具有本机Windows sudo（因此问题可能不属于此处，尽管我可以接受仅通过Powershell可用的选项）。我从一开始就使用Powershell，并且已经看到了sudo脚本的99种变体，例如上面的Invoke-Elevated （或者我每天使用的

对我来说，令人烦恼的事情之一是它启动了一个新的Shell窗口（不适用于linux），我想在Powershell / Windows中实现它，不确定在技术上是否可以在Windows上实现。

majkinetor 于 2017-05-23

👍7

尽管我喜欢另一个可以在Windows中使用的cmdlet（“ Invoke-Elevated”）的想法，但是我不明白为什么如果您需要创建一个脚本来以很高的速度运行，为什么不坚持使用“ sudo”打开PowerShell特权？

特别是如果您要自动执行一项任务，该任务最终将计划以某种高特权凭证运行。
:)

MaximoTrinidad 于 2017-05-23

因为那不是典型的工作流程。您不会“ sudo”而永远生活在那里，而是使用sudo特定命令并生活在非sudo世界中。在Windows中没有快速的方法来执行此操作，并且Powershell本身的启动速度非常慢，尤其是其中包含很少的配置文件元素时。

在一个典型的日常会话中，我对特定命令执行sudo 20次，其他命令则无特权运行。这就是sudo的全部内容，仅在必要时才可能增加特权，并且可能经常需要特权。

我的工作流程是运行命令，它抱怨特权，我sudo -L将再次以特权再次执行上一个命令。由于posh的启动速度如此之慢，所以我只是启动admin shell并不断地使用它，这显然不是一个好主意。

majkinetor 于 2017-05-23

👍4

谢谢@majkinetor！
:)

MaximoTrinidad 于 2017-05-23

👍2

sudo应该是UAC提示符的CLI变体。 Windows直到最近都从未与CLI友好，但现在我认为我们需要这样做。是时候只能在shell中完成100％Windows了-我个人只是使用shell和浏览器，几乎没有别的了。

majkinetor 于 2017-05-23

👍11 ❤3

@majkinetor ：据我所知，启动提升
FWIW：您可以使用ShellExecuteEx在Windows上完成此操作而无需更改Powershell。
但是，如果您希望流回结果，请执行以下操作：这是一个非常不同的故事。

dantraMSFT 于 2017-05-23

据我所知，启动提升级别进程的唯一方法是通过UAC提示符。

可以从UAC中排除特定的应用程序，我可以假设然后以自己的方式处理海拔。

majkinetor 于 2017-05-23

想要为Windows上的Sudo提供我的解决方案/解决方法。任何反馈/批评都将受到欢迎。如果不适合在此发布此类信息，我事先表示歉意。

https://github.com/pldmgg/misc-powershell/tree/master/MyModules/Sudo

https://www.powershellgallery.com/packages/Sudo

Sudo模块中有三个功能：

新的SudoSession
删除-SudoSession
开始SudoSession

Start-SudoSession（别名“ sudo”）用于需要提升的一次性命令。在执行命令之前，它将提示您输入凭据，并给您UAC提示。

。例

$ModuleToInstall = "PackageManagement"
$LatestVersion = $(Find-Module PackageManagement).Version
# PLEASE NOTE the use of single quotes in the below $InstallModuleExpression string
$InstallModuleExpression = 'Install-Module -Name $ModuleToInstall -RequiredVersion $LatestVersion'
Start-SudoSession -Credentials $MyCreds -Expression $InstallModuleExpression

New-SudoSession，如果用于打开一个ElevatedPSSession，可以在其中注入提升的命令。这个想法是，在具有多个需要提升的多个操作的较长脚本中，您需要在开头创建一个ElevatedPSSession并收到UAC提示ONCE，然后在需要时使用Invoke-Command将这些提升的命令注入该ElevatedPSSession中。

。例

PS C:\Users\zeroadmin> $MyElevatedSession = New-SudoSession -UserName zeroadmin -Credentials $MyCreds
PS C:\Users\zeroadmin> Get-PSSession
 Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability
 -- ----            ------------    ------------    -----         -----------------     ------------
  1 ElevatedSess... localhost       RemoteMachine   Opened        Microsoft.PowerShell     Available

PS C:\Users\zeroadmin> Invoke-Command -Session $MyElevatedSession.ElevatedPSSession -Scriptblock {Install-Package Nuget.CommandLine -Source chocolatey}

最后，Remove-SudoSession删除由New-SudoSession函数创建的ElevatedPSSession。想法是将其放置在脚本的末尾，这时您将收到一个UAC提示。因此，总的来说，要在特定脚本中运行任意数量的提升操作，您只会遇到两个UAC提示-一个打开ElevatedPSSession，另一个关闭它。 Remove-PSSession用法：

。例

$MyElevatedSession = New-SudoSession -UserName zeroadmin -Credentials $MyCreds
PS C:\Users\zeroadmin> Get-PSSession
 Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability
 -- ----            ------------    ------------    -----         -----------------     ------------
  1 ElevatedSess... localhost       RemoteMachine   Opened        Microsoft.PowerShell     Available

Remove-SudoSession -Credentials $MyCreds -OriginalConfigInfo $MyElevatedSession.OriginalWSManAndRegistryStatus -SessionToRemove $MyElevatedSession.ElevatedPSSession

在幕后，这是从非提升PowerShell会话中执行的操作（如果该会话已经提升，则不执行任何操作）：

检查以确保WinRM / WSMan已启用并配置为允许CredSSP身份验证（如果未启用，则
进行配置更改）
检查本地组策略对象...
计算机配置->管理模板->系统->凭据委派->允许委派新凭据
...确保已启用并配置为允许通过WSMAN / LocalHostFQDN进行连接
使用New-PSSession cmdlet创建高架PSSession
运行传递给Elevated PSSession中-Expression参数的表达式
删除Elevated PSSession并将所有所做的更改（如果有）还原到本地组策略和WSMAN / WinRM配置。

编辑：更新了Remove-SudoSession示例拼写错误。

pldmgg 于 2017-06-09

👍6

@pldmgg我看不到您的代码所使用的许可证，因此我们什至无法查看您所做的事情。您可以添加许可证文件吗？麻省理工学院将是最友好的，允许我们使用您的代码或从中获取代码。谢谢！

SteveL-MSFT 于 2017-06-09

@pldmgg在@ SteveL-MSFT所提到的https：//choosealicense.com/是帮助您完成此过程的重要指南。

tl; dr-使用以下许可证很难出错：

阿帕奇2.0
麻省理工学院

更多细节

与MIT相比，Apache 2.0具有其他优势，但总的来说，它们是非常宽松的，并且易于与其他开放源代码许可一起使用，并且非常友好。如果您选择任何copyleft许可证（GPL），那么只有将那些其他工具移至GPL许可证（也称为病毒性许可证）的情况下，该代码才能与其他工具一起使用-LGPL是此处的例外，其中LGPL许可的模块/二进制文件可以放置在其他工具旁边，而无需将许可证更改为其他代码。

ferventcoder 于 2017-06-09

@pldmgg也非常非常酷！

ferventcoder 于 2017-06-09

@ferventcoder感谢您提供参考https://choosealicense.com！你们（+ @ SteveL-MSFT）可能会怀疑，我不太确定该选择哪种许可证。我更新了整个misc-powershell存储库以使用Apache 2.0，并更新了Sudo.psd1以引用Apache 2.0（在我的git存储库和PowerShell库中）。希望这对人们有用！欢迎所有建议/批评！

pldmgg 于 2017-06-10

@ SteveL-MSFT如果许可证是Apache 2.0，可以使用它吗？如果您需要成为MIT，请告诉我，我会进行更新。

pldmgg 于 2017-06-10

@pldmgg我与您的解决方案最大的问题是使用CredSSP。这是一种不太安全的凭据处理方法，我认为UAC边界面临很多风险。

引用Powershell Magaize的话，

“使用CredSSP通过域管理员帐户向用户的工作站进行身份验证是一个坏主意；实际上，您是在向王国提供密钥。”

“不要在低信任度的计算机上放置高信任度的凭据”

UAC的全部要点是关于不信任计算机上的应用程序。尽管我可能同意一个sudo命令，但该命令最终在我的计算机上运行了浩劫，但它通常没有我的凭据。如果sudo命令现在可以清楚地访问我的域凭据，则可能在损害我的网络方面造成更大的损失。

如果没有CredSSP，能否使您的解决方案正常工作？如果不是，您在使用CredSSP时要解决什么问题？该信息可能对PowerShell团队找到更安全的解决方案很有用。

dragonwolf83 于 2017-06-11

@pldmgg我相信Apache 2.0足够了。谢谢！

SteveL-MSFT 于 2017-06-11

@ dragonwolf83这是一个普遍关注的问题。我实际上提出了整个论点，认为在此线程中的这种特定情况下是可以的：

https://www.reddit.com/r/PowerShell/comments/6c778m/startsudosession_sudo_for_powershell_write_in/dhsretm/

但是，总而言之，我认为这里还可以，因为：

它正在连接到本地主机（不是远程）
从Windows 8.1 / Server 2012R2开始，CredSSP不再以明文形式发送密码
远程桌面协议仍然像CredSSP一样容易受到散列攻击的侵害，因此，如果您担心CredSSP会遇到这种情况，那么您也应该担心RDP的问题。（当然，有RDP受限管理模式或新的“凭据保护”）

附言：本文已成为我对PowerShell安全性的参考（并且是我了解Credential Guard的地方）。我强烈推荐它。

https://blogs.msdn.microsoft.com/daviddasneves/2017/05/25/powershell-security-at-enterprise-customers

pldmgg 于 2017-06-13

👍4

对于6.0.0，我认为最终结果是：

名为sudo的脚本功能仅在Linux上存在（我们推迟了Windows提升支持）。如果参数是cmdlet / scriptblock，则它将对这些参数使用sudo powershell。这确实意味着目前，流水线对象将无法工作。如果参数是本机命令，我们将其直接传递给sudo。

在6.0.0之后，我们希望最终获得如下体验：

Get-Item foo.txt | sudo Remove-Item

并使其在Windows和Linux上均可使用。 cc @joeyaiello

SteveL-MSFT 于 2017-06-14

👍3 😕2

基于@ PowerShell / powershell-committee讨论，对于6.0.0而言，这不是必需的，建议您投资$$$ Invoke-AsUser类型的cmdlet

SteveL-MSFT 于 2017-07-28

👍4

通常，要更改海拔高度，您需要在UNIX下使用setuid位的东西，而这本身就是sudo。 sudo是一个特殊的二进制文件，不能轻易模拟，并且出于安全考虑，不应进行模拟。请让实际的sudo用于启动运行有关命令的powershell的临时实例。而且，考虑到一个人可能忘记了在远程服务器上打开的外壳程序，因此对整个外壳程序进行加密是相当不安全的。 sudo具有一种机制，可以在几分钟后忘记用户升起，从长远来看可以保护机器。解决此问题的方法将使更多的人可以在Linux服务器上的生产中使用Powershell。从目前的情况来看，由于安全性在生产中至关重要，因此Powershell将仍然是副产品。

borgdylan 于 2017-12-30

@borgdylan今天，您可以在PowerShell Core中执行sudo pwsh -c foo （或仅执行sudo nativecmd ）。我认为希望能够在现有PowerShell Core会话中对cmdlet进行sudo。我们不是在这里尝试重新创建sudo ，而是使用一些语法糖使其更易于使用。

SteveL-MSFT 于 2018-01-02

👍6

随着＃1527的到来，这个问题变得越来越重要，我开始怀疑：每个人都真的很愿意登录root会话来做管理员吗？当以任何方式涉及PS时，实际上没有方便的方法来调用PowerShell命令。

MathiasMagnus 于 2018-02-04

@MathiasMagnus我还没有

mark ALL=(ALL:ALL) NOPASSWD: /usr/bin/pwsh

然后，我能够通过PowerShell SSH远程会话调用sudo pwsh -c 'cat /etc/sudoers' 。根据您的安全状况以及在sudoers中的确切配置（例如， All=(ALL:ALL)有点开放...），这可能是安全或危险的。

如果您使用ssh到Linux（即使用bash shell而不是PowerShell SSH远程处理），就我所知，您可以在pwsh内使用普通密码提示运行sudo。

并不是说不可能，只是当前的解决方法是随身携带的。

markekraus 于 2018-02-04

@MathiasMagnus ＃1527仍适用于6.1.0，因为目前尚无很好的解决方法。对于cmdlet，主要问题是与sudo'd cmdlet进行流水线处理的复杂性。对于单个操作， sudo pwsh -c是可行的。当然，如果社区中有人提交了PR，我们将非常乐意接受。

SteveL-MSFT 于 2018-02-05

在Windows上，这是一个我认为不提高ssh连接就无法解决的问题，然后需要一种从命令行提升的方法。

parkovski 于 2018-02-11

👍3

我知道很容易就无法解决问题并且没有采取行动的事情进行调查，但是我的专长却在其他地方。我主要为C ++和GPGPU库以及Vcpkg做了大量的CMake移植。我从未写过C＃，而且我认为我没有能力。但是，我确实管理着约12台机器的小型集群。它处于可以手动管理的边界，但是sudo功能严重缺失，也就是说，如果我不打算在Ubuntu上为root用户创建登录名，那是不受欢迎的。 DSC Core将是一个解决方案，但即使它在一年前就已宣布，但最近仍被无限期推迟。

目前使用的Linux上的PowerShell Core有点介于自动化的工作方式和Linux系统管理员熟悉的临时样式之间。我希望有人能抽出时间来解决这个问题。

MathiasMagnus 于 2018-10-02

@MathiasMagnus这是每个人都想要的东西，但这并不是一个简单的问题要解决。请注意，对本机命令使用sudo可以正常工作，实际上不能对cmdlet运行sudo 。解决方法是在pwsh中调用pwsh：

sudo pwsh -c删除项目

主要的复杂之处在于管道中的东西：

get-item foo * | 须藤删除项目

SteveL-MSFT 于 2018-10-02

@ SteveL-MSFT至少这个概念并不复杂。请告诉我你的想法。

我们只需要sudo，su和login二进制文件的组合即可处理所有情况。

它需要做：

为回调创建一个unix套接字，并且仅允许目标用户访问它。
验证调用者是否允许sudo访问（我认为可以简单地复制su ， sudo和login的源代码）
- 如果/ etc / sudoers存在，则需要对其进行解析
  - 仅特定命令
  - 通过使用目标用户密码
  - 不验证凭据（无密码）
- 如果不是，则需要调用pem来检查用户是否直接“知道”用户root的凭据。
- 如果他也不知道目标用户的凭据，请拒绝访问并在Powershell中引发异常。
如果验证通过，则需要将用户上下文切换为root用户或目标用户。
一旦我们切换了用户上下文，新进程就需要通过将其连接到unix套接字来建立与运行的原始powershell的通信。
如果用户输入“ exit”，我们将通过unix套接字发出信号，表明操作已完成，退出时，用户将自动返回调用者特权，因此我们只需要托管Powershell来显示提示或执行下一个指令。
相反，如果主机Powershell终止，则Unix套接字将关闭，升高的Powershell应停止执行并终止，就像关闭终端一样。

执行流程如下所示：
PWSH（创建套接字/proc/self/change-user.socket）=> PWSH-SU（使用套接字和目标用户作为参数调用； PWSH-SU设置为suid以本身作为root用户运行）=> PWSH（目标用户连接）到unix套接字。

最耗时的部分是允许Powershell通过UNIX套接字在内部进行连接。仅重定向输入和输出链接到其他unix应用程序是不够的，因为调用管道时，我们不仅处理字符串，还处理对象。

为什么要使用所有三个二进制文件？
必须使用sudo ，以允许多个用户切换到root上下文而又不会失去可审核性。
su用于通过使用目标用户凭据来切换到任何其他用户。
login用于创建一个全新的登录会话。
与只有一种功能相比，在Powershell中还具有所有这些功能可能会很有用。

agowa338 于 2018-12-06

👍1

使用管道也可以在Windows上以一种不太令人惊讶且更方便的方式进行此工作-我讨厌使用所有“ sudo”脚本+ UAC单击获得另一个Shell，但是使用这样的管道可以在同一个Shell中完成例如在Linux上，通过管道与已经以admin身份运行的另一个解释器进行管道通信，并可能实现一些真正的sudo内容（例如，提示超时或使用命令替代自定义Powershell端点的sudoers文件）

majkinetor 于 2018-12-06

👍1

我很高兴看到关于此问题的想法，但是就实际的实现而言，在我看来，我们已经领先了一步。第一件事是系统需要一种方法来创建提升的进程，线程，无论是未提升的线程。如果我们不通过UAC就无法创建PowerShell的增强实例，则无法真正解决cmdlet的所有问题。 IMO，这里要解决的第一种情况应该是-SSH会话受限-如何使用管理员权限执行常规exe？

我在这里开始对此进行试验（由于重构，目前已失效，但是该概念有效），但我认为第三方应用程序不是真正的解决方案。我希望看到Windows首先发布“ sudo” exe。这可以像使runas具有凭据提示来创建提升的过程一样简单，但是如果没有第一步，这一切都是理论上的。

parkovski 于 2018-12-11

如果我们不通过UAC就无法创建PowerShell的提升实例，则无法真正解决所有cmdlet问题。

一种可能的方法是将计划任务与选项“以最高特权运行”一起使用。

majkinetor 于 2018-12-11

是的，但是要创建它，您必须已经具有管理员权限吗？ psexec就是这样做的。据我所知，现在，您必须在某个时候通过UAC。我希望看到这种变化，并且随着所有SSH会话的提升，这是一种安全隐患。如果某些粗略的软件试图通过SSH进入我的Windows计算机，例如从另一台我设置了私钥（或回送方案）的计算机上，它可以执行任何所需的操作。

parkovski 于 2018-12-11

@parkovski我的解决方案是Linux / MacOS和所有其他* NIX OS。 Windows不支持SUID和GUID。
由于Windows上目前还不存在sudo，因此对我而言，它不在此问题范围内。

为了解决UAC问题，Windows将来应实现SUID和GUID。所有其他一切只是一个长期问题的肮脏解决方法...

agowa338 于 2018-12-12

是的，但是要创建它，您必须已经具有管理员权限吗？

是的，但是不会触发UAC弹出窗口。

微软的应用程序兼容性工具包也可以跳过UAC的官方方式。

Windows不支持SUID和GUID。

Windows不必支持它，并且该概念在该OS上无效。
其权限模型基于ACL，并且没有单个组所有权。

它也不必是Windows上的完整sudo副本，只是调用管理命令的一种更友好的方式。

majkinetor 于 2018-12-13

👍1

我认为最好推迟Windows支持，因为Windows用户可能已经习惯于今天打开提升的PowerShell会话，而Linux用户希望根据需要以非root用户和sudo的身份运行。我们只想确保任何设计都不会排除将来对Windows的支持。我可能还会集中精力于简单地为root启用sudo，而不是任何任意用户来简化它，我相信这是使用量的90％以上。

SteveL-MSFT 于 2018-12-20

👍5

@ SteveL-MSFT

也可能只专注于为root而不是任何任意用户启用sudo

我认为这不会有什么大不同，但是可以为我上面概述的摘要提供完整的su / sudo体验，因为将用户上下文切换到root几乎与切换到任何其他用户相同。

agowa338 于 2018-12-20

👍1

我认为最好推迟Windows支持，因为Windows用户可能已经习惯于今天打开提升的PowerShell会话

与我一起工作的大多数人都尽可能地禁用UAC。

majkinetor 于 2018-12-20

不幸的是，在许多环境中这并不是真正的选择，我非常怀疑MS是否会完全放弃UAC。 😕

vexx32 于 2018-12-20

此问题与UAC无关。但是从我的角度来看，应该完全放弃它，或者用一个严格的两个帐户替换一个管理员一个用户（并且管理员一个不能用于登录）理念（默认安装会迫使您创建它们）或* NIX具有相同的概念，您可以从用户身份开始使用sudo和SUID / SGID-Flags进行提升。

agowa338 于 2018-12-21

我最近在$profile添加了以下内容。我在https://stackoverflow.com/a/56265080/118098上进行了更详细的介绍

function Invoke-MySudo { & /usr/bin/env sudo pwsh -command "& $args" }
set-alias sudo invoke-mysudo

至少从表面上看，这对我有用，并且允许“ sudo”。这不会涉及“能够在现有的PowerShell Core会话中对cmdlet进行sudo ”（根据https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -354853084的情况）

但是，我想知道在调用命令的整个会话中赋予提升的上下文有多么重要。在其他Shell中， sudo仍在新上下文中运行提供的命令。

maxwellb 于 2019-05-22

👍2

我已经实现了一个基本的sudo，可以很好地在Windows上以管理员身份运行命令。我不确定这是否也可以在linux / mac上使用，因为我不知道“ RunAs”在这些平台上是否正确提升。

编辑您的个人资料：

PS > notepad $PROFILE

添加以下sudo函数：

function sudo {
    Start-Process -Verb RunAs -FilePath "pwsh" -ArgumentList (@("-NoExit", "-Command") + $args)
}

然后在您的外壳中调用。支持cmdlet，可执行文件以及通常可以在PS提示符下键入的任何内容：

PS > sudo Remove-Item .\test.txt  # Remove a file
PS > sudo Copy-Item .\test.txt C:\  # Copy a file
PS > sudo net start w3svc  # Start IIS

如果要传递将在运行时求值而不是预先求值的变量或表达式，请用大括号括起来。例如：

PS > $myvar = "a"
PS > sudo echo $myvar  # $myvar is pre-evaluated, so the command reads: sudo echo "a"
PS > sudo { $PSVersionTable }  # with braces, $PSVersionTable is not evaluated until it is run as administrator

如果您希望在完成后关闭管理员窗口，请从sudo函数中删除"-NoExit" 。

vsalvino 于 2019-06-10

@vsalvino当GUI可用时，这是一个有用的解决方法，同时也很有用，但这仍然不是真正的sudo，因为如果没有GUI访问，它就无法工作。实际上，在远程外壳程序（ssh）中，实现此工作的唯一方法是服务和客户端，正如我在此处尝试演示的那样。

为了解决一些常见的建议，因为相信我，我研究了所有可能性：

禁用UAC不是解决方案。这是一种可以作为个人选择的解决方法，但这不是解决此问题的一般方法。
弹出UAC的所有内容（我见过的每个“ sudo”脚本）都不是解决方案，包括执行一次以启动提升的远程会话。
所有需要GUI的东西都不是解决方案。假设我们在这里使用ssh并且GUI不可用。
任何需要对Windows进行重大更改的方法都不是解决方案。我们不能指望UAC会变得更好。
即使来自Microsoft的签名二进制文件也不是解决方案，因为当UAC设置为高时，它将不起作用（我在wsudo自述文件中弄错了；稍后将对其进行纠正）。
Windows上sudo唯一真正的解决方案是一项服务，该服务可在成功进行身份验证时提升用户进程。 我希望听到其他想法，但请先进行研究。

基本上，有人将不得不做很多工作，而没有办法解决。一旦PowerShell在Unix上支持此功能，我们所需要的就是在Windows上的替代功能下降，并且可以按您期望的方式工作sudo（无GUI，无UAC）。

parkovski 于 2019-06-11

👍1

我们可以先澄清一下这个问题的范围吗？我认为现在有很多人在谈论不同的话题。
是这个问题吗？
a）关于在Linux / Mac系统的Powershell中实现sudo？
b）在Windows中实现sudo副本？
c）允许在psremoting时提升特权？
d）允许在Windows上模拟其他用户？
e）允许从非特权用户帐户切换到特权用户帐户？
f）完全不同的东西？

对于a）https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067
对于b）与a相同（Windows也具有unix套接字），但是它需要由服务生成（而不是suid二进制文件）（在具有“充当操作系统一部分”特权的用户内运行，例如用户系统），并且该服务还需要检查特权。或在Windows上实现SUID / GUID概念。
对于c）不需要，您在远程处理时已经具有最高特权。访问远程主机时，没有特权分离（也已经有一些本地主机回送UAC旁路以这种方式工作）。
对于d），也可以采用a / b的方法，但是我不知道在尝试访问网络资源时该方法如何工作，而又不知道用户凭据或创建新的Windows / Active Directory身份验证后端。
对于e）与b相同，但是还需要凭据检查，或者可以放宽runas api，以允许一个知道用户名和密码的用户获取新的用户令牌并控制该过程。（不太可能考虑UAC安全概念和注意事项，因此我们回到b）。

agowa338 于 2019-06-11

👍1

IMO，此问题应与在已经存在基础功能的PowerShell中实现sudo有关。在本终端问题中，讨论Windows的sudo等效项可能更合适。

parkovski 于 2019-06-11

👍1

关于Windows的sudo等效项的讨论可能更适合于此终端问题。

鉴于终端应用程序是CLI世界的又一个前端，为什么将它作为讨论sudo的更好场所？按照相同的逻辑，您可以在ConEmu存储库中提交票证。

IMO，此问题应与在已经存在基础功能的PowerShell中实现sudo有关。

下一个Powershell的要点之一是使用它的系统之间的兼容性问题较少。关于这一点，IMO不接受仅在系统X上执行操作。

作为CLI用户，我不关心sudo是使用suders文件还是某些Windows操作系统的完整Linux sudo。 Sudo只是OS提升功能的接口。无论“后端”如何，都可以使这种接口几乎相同地工作。

否则， @ parkovski指出GUI立场-我只是在其中添加Windows Core。

majkinetor 于 2019-06-11

鉴于终端应用程序是CLI世界的又一个前端，为什么将它作为讨论sudo的更好场所？按照相同的逻辑，您可以在ConEmu存储库中提交票证。

因为该回购不只是“终端应用程序”；运行它的团队基本上拥有Windows的文本模式部分，并且已经表示，他们会在有时间的时候对sudo感兴趣。另一方面，PowerShell团队和ConEmu都没有提供。

我之所以认为Windows sudo不在范围之内，是因为我们已经确定正确执行它是一项相当大的工作，并且与PowerShell本身正交。 PowerShell可以在存在时使用它，但实际上它是任何特定外壳中的独立组件。

另一方面，PowerShell能够通过sudo二进制文件运行cmdlet，而不管平台或二进制文件的实际工作方式如何，这完全是PowerShell的一部分，PowerShell属于此处。

作为CLI用户，我不关心sudo是否是使用suders文件或类似Windows的完整linux sudo。 Sudo只是OS提升功能的接口。无论“后端”如何，都可以使这种接口几乎相同地工作。

是的，绝对应该。只是sudo在Windows上尚不存在，将需要大量工作，并且可能不会由PowerShell团队编写。当存在这种情况时，我们希望PowerShell能够以一种也可以在Windows上运行的方式来实现它。

无论如何，我将推迟进一步的评论，直到我们在这里得到正式答复，因为这个问题正在朝着不同的方向发展。

parkovski 于 2019-06-11

👍6

有什么意见吗？
http://blog.lukesampson.com/sudo-for-windows
安装了scoop install sudo ，它是我能想到的最接近的。它的工作方式类似于unix sudo-使用仰角运行命令。我为所有用户使用pip或Install-Module。

Luke Sampson-Windows的Sudo
Windows版Sudo

Witchilich 于 2019-12-07

@ Restia666Ashdoll如果将其重命名为Invoke-ElevatedCommand我可以接受。
这是因为sudo不仅负责提升命令，而且还负责模拟用户和“放弃”（ sudo -u nobody command ）特权。事实证明，重用已经存在的名称不是一个好主意，特别是在功能和参数不同的情况下。
我已经在上面概述了具有模拟功能的真正sudo的外观以及其工作方式。

agowa338 于 2019-12-08

👍1

@ Restia666Ashdoll请在此线程中阅读此注释。

parkovski 于 2019-12-09

@parkovski那只是-Verb RunAs的包装，仅适用于一些命令。我链接到的那个几乎可以用于所有内容。例如，我这样使用它- sudo pip install httpie 。

Witchilich 于 2019-12-09

您没有阅读我的帖子吗？

parkovski 于 2019-12-10

我不认为有任何方法可以编辑标题，使其包含诸如“ WINDOWS讨论中不存在任何疑问”之类的内容？我知道我个人没有义务继续回答这个问题，但是人们会不断地在不做研究的情况下说同样的话。

parkovski 于 2019-12-10

我试图单击此人的退订链接，但不幸的是，如果不以他的身份登录，它不会允许我这样做。

parkovski 于 2019-12-10

我已经向GitHub报告了@troymoore

SteveL-MSFT 于 2019-12-10

👍2

我想提出一个独特的和不同的解决方案，我在这里没有提到过。使用诸如命名管道之类的命令将命令序列化到提升的进程，然后将其序列化的输出返回给调用进程，该怎么办？

这是一个功能模块，演示了如何在NT上工作： https :

当然，它不是完美的，但是它可以在不打开另一个控制台的情况下完成简单任务和提示线的提升。我不打算将其本身像sudo一样，因为我不相信克隆sudo的设计将是最好的长期解决方案，但是我认为针对这个模糊的海拔问题采用不同的方法可能会进一步进行建设性的讨论。

编辑：我还应该提到，这将无法完成@parkovski对于UACless高程的请求。

ghost 于 2019-12-11

👍1

看起来像JEA。
至于序列化，并非所有模块都支持。

iSazonov 于 2019-12-11

看起来像JEA。

是的，就是这个想法。

至于序列化，并非所有模块都支持。

就像您在代码中可能看到的那样，通过在管道另一端重构代码的文本流可以缓解这种情况。我承认这很慢，但是仍然是一种新颖的解决方法。您在这里提到JEA再次成为一个有影响力的因素。如果不需要提高某人代码的某个部分，则不需要。

该模块旨在解决一个非常具体的问题，即在NT上的GUI会话中提升交互命令，仅此而已。事情开始于五年前，当时还没有人想到NT可能是native ssh。我同意@parkovski的观点，这是一个与NT如何处理提升有关的问题，因此，如果没有服务侦听并提供轮廓形式的命令提升，很难实现类似于sudo，pkexec或doas的易用性案例。

但是，不是被涅磐般的谬论所制止，在PowerShell可以支持任何形式的命令提升之前，NT上必须存在类似于sudo的实现，我们为什么不首先在shell会话中推动任何形式的JEA交互式提升呢？

这至少将促进北领地世界改进安全实践。为什么不同时实现一个cmdlet以交互方式运行和一个cmdlet来启动单独的控制台会话呢？甚至更好，只是推广当前的方式来启动提升的会话，同时使用更精简的具有不同用例的cmdlet集？这至少是前进的一步。

我可能还要补充一点，即使Python elevate库也无法完成此模块的工作。您是否找到了另一个无法使用的模块？因为我的主要观点是，也许比我更聪明的人可以采用此模块及其思想，并以适合NT的方向运行它。之后，我们可能会在中间遇到一个用于NT和* nix的平台，这使我们可以修改PowerShell的更常见实现以提升命令。

至少那是我的两分钱。但是，看过代码后，如果觉得其中的想法不好，我会理解的。我只是还没有看到任何人尝试过这种方法。

ghost 于 2019-12-11

👍1

我会从沮丧的痛苦中退缩一分钟，以解释sudo的问题，因为（a）是的，这是一个非常困难的问题，（b）实际上只能由MS正确解决（感谢您不是Windows的开源人，）（c）看到其他人也对此充满热情真的很酷。

我知道正确地做到这一点有多困难，因为我是从那条路开始的。因此，如果目前唯一阻止我们这样做的是UAC对话框，那就这样吧。至少通过这种方式，我们可以轻松地测试跨平台解决方案。

我个人希望从PowerShell中看到的是对Unix sudo的全面支持，但是它旨在支持某种形式的“ pseudo-sudo”脚本，因为它现在以及将来可能的实际Windows sudo都支持。我的想法是，如果有人原型化Windows sudo最终将如何工作，但不考虑UAC限制，它应该相当简单，给我们提供基本上与现在一样好的东西，而当我们得到真正的东西时，它应该很漂亮只是一个即插即用的替代品。

显然，这意味着某人将不得不提出一个模型，该模型可以理解或至少转换为Unix uid / gid模型和Windows sid / acl模型。希望这个人喜欢挑战。猜测这还需要与MS中的终端和Windows安全团队进行一些讨论。

我猜想随着越来越多的人创建了自己的最大努力变通办法，并且支持这样的事情很可能有助于设计一种强大的方法来实现此目的，为什么不呢？

旁注-编写这些变通办法脚本的任何人都可能会考虑sudo具有的超时功能，就像弹出窗口一样令人讨厌。

parkovski 于 2019-12-11

我们可以考虑一下Start-Process pwsh -NoNewWindow -Credential $cred 。它不起作用，但是可以。

iSazonov 于 2019-12-11

显然，这意味着某人将不得不提出一个模型，该模型可以理解或至少转换为Unix uid / gid模型和Windows sid / acl模型。希望这个人喜欢挑战。猜测这还需要与MS中的终端和Windows安全团队进行一些讨论。

Unix也具有acls，而Windows具有posix兼容性，至少如果它是域联合的，那么还有一个我们可以使用的主组属性（以及posix属性）。它只是需要为非域加入的Windows客户端（或现在假定为User ）实现。

因此，unix和Windows权限的通用模型基本上是：
具有拥有用户和拥有某些预期ACE（用户，组及其他）的拥有组的ACL。

比我们可以将unix权限映射为：
uid =>所有者SID
gid =>创建对象的用户的主要组SID。
用户=>创建者所有者ID S-1-3-0
组=>创建者组ID S-1-3-1
其他=>世界/每个人S-1-1-0
从unix的acl列表映射uid有点复杂，因为我们需要考虑系统可能是ldap，活动目录或任何其他目录的一部分。在powershell范围内，我只考虑两种情况：无目录和ldap / active目录。
在第一种情况下，我建议使用S-1-6-1-uid和S-1-6-2-gid（假设S-1-6仍然可用，并且负责的团队愿意为此分配它）。
对于第二种情况，我们只需要通过身份验证后端解决uid。 ldap / active目录服务器则负责提供sid。
最后，有一些特殊情况要映射：
uid 0 => S-1-5-32-544
gid 0 => S-1-6-500（和S-1-5-21-*-500）
其他大多数著名的sid都可以通过配置文件或某种api进行管理（或者将其删除，因为它们很可能始终未被使用）

如果我们在外壳中执行此操作，则诸如Get-Acl / Set-Acl之类的命令将开始在unix系统上工作，而无需了解权限如何存储在磁盘上。

@ mmillar-bolis我已经在这里建议了使用套接字的方法： https :

agowa338 于 2019-12-12

我们可以考虑启动进程pwsh -NoNewWindow -Credential $ cred。它不起作用，但是可以。

更新： .Net Core （我想也是Windows API）不允许运行附加到同一控制台的新进程。

因此，我们可以使用的单一方法是提升的Windows服务。但是我们必须为每个“ sudo”创建这样的服务过程以确保安全。
因此，解决方案是将New-PSSession（或在PSSession中调用）以具有提升的用户凭据的方式提供给localhost。

iSazonov 于 2019-12-12

@iSazonov允许您将其附加到同一控制台的唯一一件事就是我在这里已经提到的内容： https :

现在Windows支持unix套接字了，我们可以使用它们或命名管道，并且特权服务将负责验证凭据，并且需要一直运行（与* nix oses的链接发布中提到的通过suid调用相比）。

也许lsas将/需要扩展以提供这种身份验证api功能吗？
这样，我们就可以完全模拟，同时仍然可以安全地附加到同一控制台并接受输入。

agowa338 于 2019-12-14

@ agowa338您的建议“事实上”是PowerShell远程处理。它已经实现。

iSazonov 于 2019-12-14

👍1

但

因此，解决方案是将New-PSSession（或在PSSession中调用）以具有提升的用户凭据的方式提供给localhost。

不适用于localhost。它仅引发AccessDenied。

除了以下情况之一：

UAC已关闭
您尝试在未启用“管理员批准模式”的情况下连接到BUILDIN \ Administrator。
进程（Powershell）已经提升。

这是一个很好的解释，为什么是@ jborean93 ： https :

因此，我们需要充当代理的特权服务，或者需要更改其中一个API，但这不是我们在PowerShell / PowerShell中可以做的事情，需要由Microsoft内部人员委派。

agowa338 于 2019-12-14

@ agowa338您引用的注释是关于本地Windows API的，而不是有关PowerShell Remoting的问题。

iSazonov 于 2019-12-14

@iSazonov ：您是否尝试过将不适用于上述原因

PowerShell远程处理到localhost不允许在本地计算机上获得提升的特权。

但是，PowerShell远程授予您网络上除localhost

这就是为什么我们在Windows上需要一个sudo等效项的原因。如果PowerShell远程处理将以这种方式运行，那么您认为可以通过在文档中编写示例来关闭此故障单，因为该功能已经存在。

agowa338 于 2019-12-14

@ agowa338由于安全保护，它不适用于您。它不是操作系统功能。您可以按照docs https://docs.microsoft.com/zh-cn/powershell/module/microsoft.powershell.core/about/about_about_remote_troubleshooting中的说明配置WinRM。您引用的问题还说这对SSH有效（步骤已在本文中引用）。

因为功能已经存在。

请求是开始工作“ sudo Remove-Item foo.txt，其中foo.txt由根拥有”。
它不起作用，但是我们想要。
该问题包括两个部分：语言的语法糖和实现。

如果您对提案有更多的了解，您会发现需要具有每个用户/每个会话/每个运行空间/每个作用域的PowerShell上下文。然后，您必须解决安全合规性要求，并且在默认配置中您将获得“访问被拒绝”。之后，您的建议将与已经实施的PowerShell远程处理相同。

about_Remote_Troubleshooting-PowerShell

iSazonov 于 2019-12-14

由于安全保护，它对您不起作用。它不是操作系统功能。您可以按照文档中所述配置WinRM

@iSazonov您能详细说明一下吗？我可以从该计算机远程访问，也可以从任何计算机远程访问网络中的任何其他计算机，但从任何一个都不到本地主机。是的，我读了那页。

请求是开始工作“ sudo Remove-Item foo.txt，其中foo.txt由根拥有”。

对于非Windows系统，我们可以使用unix套接字方法来实现模拟/提升，以便在那里进行Powershell远程处理。

agowa338 于 2019-12-14

您能再详细说明一下吗？我可以从该计算机远程访问，也可以从任何计算机远程访问网络中的任何其他计算机，但从任何一个都不到本地主机。是的，我读了那页。

大多数攻击都针对本地海拔。因此，所有配置都是“默认情况下是安全的”。 WMI，WinRM，IIS回送等-所有子系统均禁用允许局部高程的功能。
对于讨论而言，它并不那么重要。即使PowerShell远程处理不允许默认情况下执行sudo，我们也可以实现默认情况下将其关闭或仅允许交互式会话。

您开始谈论Windows，对于非Windows系统，我们可以使用unix套接字方法来实现模拟/提升，以在那里进行Powershell远程处理。

我们应该为所有平台使用相同的UX。确实，PSRP通过传输-WinRM或SSH起作用。 MSFT表示他们喜欢SSH，但是在过去两年中我看不到任何明显的进展。令人难以置信的是，他们将在不久的将来想要第三个协议-太多的工作（需要保持与旧系统的兼容性）。

iSazonov 于 2019-12-14

大多数攻击都针对本地海拔。因此，所有配置都是“默认情况下是安全的”。 WMI，WinRM，IIS回送等-所有子系统均禁用允许局部高程的功能。
对于讨论而言，它并不那么重要。即使PowerShell远程处理不允许默认情况下执行sudo，我们也可以实现默认情况下将其关闭或仅允许交互式会话。

不久前，我试图启用它，许多其他人反复告诉我，这在内部受到os的限制，没有应用程序深入Windows内部，这是不可能的。实际上，许多人已经指出了以上提到的Windows api限制，并以此为理由说明为什么Powershell永远无法提供这种功能。甚至有人引用了CVE，其中故意删除了环回升高。因此，对这个兔子的陷阱深表歉意，但是我需要对其进行配置以使其起作用？甚至在任何地方都有记录吗？

我们应该为所有平台使用相同的UX。确实，PSRP通过传输-WinRM或SSH起作用。 MSFT表示他们喜欢SSH，但是在过去两年中我看不到任何明显的进展。令人难以置信的是，他们将在不久的将来想要第三个协议-太多的工作（需要保持与旧系统的兼容性）。

太好了，因为这两种解决方案都可以在任何平台上工作，所以我们应该推动这两种解决方案中的任何一种。

PSRP：SSH到localhost可以在Windows和Linux上进行提升，因此，使用psrp子系统，我们已经具有正确的权限，因此只有powershell层必须统一才能允许传递对象。对？
使用unix套接字还可以提供类似于powershell远程处理的功能，但是在撰写本文时，我认为进行本地提升是很困难的限制，而没有任何类型的附加服务作为本地系统运行来执行令牌交换...

因此，由于Powershell远程处理已经存在（并且也已经超过ssh了），我们应该优先考虑该解决方案。

agowa338 于 2019-12-14

甚至有人引用了CVE，其中故意删除了环回升高。

我无法确认。我猜CVE可以默认禁用环回，但根本不能禁用。
另请参见https://github.com/PowerShell/PowerShell/issues/3874#issuecomment -510715727

iSazonov 于 2019-12-14

@iSazonov ：这不起作用，它仅提供低特权访问令牌，而不提供提升的访问令牌（例如Mandatory Label\High Mandatory Level ）。即使我将TrustedHosts设置为* ，我也无法从低特权的Powershell中获得管理权限。即使在Enter-PSSession之后，登录令牌也始终是交互式类型。
~~我实际上可以Enter-PSSession localhost -ScriptBlock {}但是传递凭据会导致“访问被拒绝”。~~ ，不，它总是会抛出其他系统禁用了uac的“访问被拒绝”。

但是我现在也使用SSH尝试了它，并且按预期工作，它提供了登录类型为Network的提升令牌（ Mandatory Label\High Mandatory Level ）。

因此，在PSCore中，我们可以依靠psrp进行提升（甚至通过Enter-PSSession -HostName localhost在本地进行，也可以与传递的显式凭据一起使用）。
其中Enter-PSSession -ComputerName localhost -Credential $foo不会（即使$ foo.Username与当前用户相同）

agowa338 于 2019-12-14

@ agowa338我认为我们不应该在这里讨论绕过WinRM的安全功能（这是合规性敏感领域）。我只能指出（1）无论协议如何，安全性都应保持在同一级别，这意味着考虑到Windows内部的工作原理，SSH环回的行为应与WinRM相同，（2）PS sudo实现应在任何运输。

iSazonov 于 2019-12-15

@iSazonov ：我没有要求利用漏洞，只是要求启用它需要配置什么。您也将成为唯一想出如何配置WinRM以便允许环回提升的人。
我尝试启用它很长时间。所有问题（关于stackoverflow，reddit，github问题等），我碰到的结尾都是“ windows wird”，“不知道windows在做什么”，“在任何地方都没有记录”，“ Windows不提供”该功能”，“改用Linux”，“禁用UAC”，“您需要编写以系统特权运行的代理服务”。因此，如果您知道了，请分享您的知识。

我只能指出（1），无论采用哪种协议，安全性都应保持在同一级别

你那是什么意思？

考虑到Windows内部的工作原理，这意味着SSH环回的行为应与WinRM相同

SSH拥有一项系统服务，可以在后台充当代理来完成此任务。它提供了一个网络访问令牌...

（2）PS sudo实现应可在任何传输上使用。

正是由于这个原因，它并没有超过WinRM。因此，如果您说的是真的，我们需要有关如何启用环回WinRM的文档。

agowa338 于 2019-12-15

如果发现了，请分享您的知识。

@ agowa338 MSFT团队要求我不要公开讨论安全性，我会遵循CoC。我支持您希望深入探讨此主题的愿望，但是作为此讨论的一部分，MSFT如何将此解决方案集成到Windows中并保持安全性合规性令人头疼。

iSazonov 于 2019-12-15

好吧，这对任何人都没有帮助。

总结一下：

您说Windows在WinRM中具有类似于sudo的功能。
既没有文档证明它存在，也没有如何启用/禁用它。
披露如何使用它会带来安全风险。

抱歉，但这听起来像是后门而非功能。除您以外的任何人都无法使用。
过去，通过默默无闻的安全性也没有起作用。

因此，我们回到目前尚未实现的状态，我们需要一个经纪人服务，而不是...

agowa338 于 2019-12-15

@ agowa338我们已经收集了足够的信息供MSFT团队总结。如果他们发现安全问题，他们将向我们展示一种可接受的替代方法。

iSazonov 于 2019-12-15

可能，但是今年年初用补丁KB4480116和任何后续的累积更新对https://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/进行了修补。.在此更新之前，可以升级如果您将LocalAccountTokenFilterPolicy设置为1（即winrm quickconfig所做的工作（对于WinRM实际上是必需的）），则将获得您的特权。

有一条注释说JEA端点不受影响，因此可能您可以创建自己的PSSessionConfiguration并连接到该端点，但我尚未对此进行测试以进行验证。我个人认为此补丁很愚蠢，因为该补丁只是阻止PowerShell客户端连接到本地主机，但是如果您知道自己在做什么，则可以轻松地绕过它。例如，我仍然可以通过使用SSH或其他PSRemoting客户端，而无需接触UAC，从受限到高级

PS C:\Users\vagrant> whoami.exe /groups  # prove the current process is limited

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
======================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Group used for deny only

BUILTIN\Administrators                                        Alias            S-1-5-32-544 Group used for deny only

BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Performance Log Users                                 Alias            S-1-5-32-559 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\REMOTE INTERACTIVE LOGON                         Well-known group S-1-5-14     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\INTERACTIVE                                      Well-known group S-1-5-4      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
LOCAL                                                         Well-known group S-1-2-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\Medium Mandatory Level                        Label            S-1-16-8192

PS C:\Users\vagrant> ssh vagrant<strong i="11">@localhost</strong> whoami.exe /groups  # prove that SSH is elevated
vagrant<strong i="12">@localhost</strong>'s password:

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
===================================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Mandatory group, Enabled by
default, Enabled group
BUILTIN\Administrators                                        Alias            S-1-5-32-544 Mandatory group, Enabled by
default, Enabled group, Group owner
BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NETWORK                                          Well-known group S-1-5-2      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\High Mandatory Level                          Label            S-1-16-12288

PS C:\Users\vagrant> python -c "from pypsrp.client import Client; c = Client('localhost', username='vagrant', password='
<password>', ssl=False); print(c.execute_ps('whoami.exe /groups')[0])"

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
===================================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Mandatory group, Enabled by
default, Enabled group
BUILTIN\Administrators                                        Alias            S-1-5-32-544 Mandatory group, Enabled by
default, Enabled group, Group owner
BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NETWORK                                          Well-known group S-1-5-2      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\High Mandatory Level                          Label            S-1-16-12288

我们可以看到，使用SSH我们有一个提升的令牌，我们也看到了使用第3方库，我们仍然可以使用localhost PSRemoting来创建提升的令牌，并且补丁不是此功能的全部模块。

我不认为这是安全问题，也不是跨越安全边界，因为MS反复说UAC不是安全边界

它可能接近或作用类似于它，但并非万无一失。绕过UAC的那些方法之一是已知的和有据可查的LocalAccountTokenFilterPolicy注册表属性。此属性的明确目的是确保始终提高网络登录名而不是过滤后的令牌，并且明确表示未启用此功能可以防止“回送”攻击

为了更好地保护属于本地Administrators组成员的用户，我们在网络上实施了UAC限制。此机制有助于防止“回送”攻击。此机制还有助于防止具有管理权限的本地恶意软件远程运行。

最终，这意味着Windows上没有真正的官方方法以非交互方式将您的特权从受限权限提升为管理员权限。使用Start-Process ... -Verb Runas非常简单，但这需要交互式登录才能显示UAC提示符。拥有类似sudo的机制将有助于缓解此问题，但正确地进行操作将需要Windows本身的工作，而不是特定于PowerShell的。有“解决方法”，但我不会将其称为正式方法，而只是启用WinRM的已知副产品。

电源外壳
Windows安全更改影响PowerShell
影响PowerShell的Windows安全更改2019年1月9日最近（1/8/2019）Windows安全补丁CVE-2019-0543为PowerShell远程处理方案引入了重大更改。这是一种范围狭窄的方案，对大多数用户的影响应该很小。重大更改仅影响本地环回远程处理，

马克的博客
PsExec，用户帐户控制和安全边界
大约一年半以前，我将-l开关引入了PsExec，这是一种通过Windows XP上的管理帐户以标准用户权限执行进程的简便方法。在以受限用户身份运行–简单方式中，我描述了PsExec如何使用CreateRestrictedToken API创建安全上下文。

工程Windows 7
UAC更新
嗨，乔恩·德瓦恩（Jon DeVaan）在这里与您讨论我们最近收到的UAC反馈。我们完成Windows 7的大部分工作都集中在响应反馈上。 UAC的反馈在工程决策过程的几个方面都很有趣。我认为探索这些维度将使e7变得有趣。

jborean93 于 2019-12-15

@iSazonov这些建议中的任何一个都不会在同一控制台session_中从_完成_user-interactive_命令的提升，特别是在_lacks UAC_的环境中。在这些问题上，您似乎可以代表Microsoft发言，因此您是否要澄清他们是否对引入我所描述的功能不感兴趣？

如果是这样的话，正如我从以上文章中解释的那样，关闭此线程似乎是谨慎的做法，因为我们其余用户将不得不在其他地方寻求解决方案，例如@parkovski的TokenServer想法。

ghost 于 2019-12-16

在这些问题上，您似乎可以代表Microsoft发言

我是该项目的社区维护者，不是MSFT成员，并且我不能代表Microsoft发言。

您能否说明他们是否对引入我所描述的功能完全不感兴趣？

_所有建议都有价值；他们都没有被拒绝。讨论只是为了收集所有可能的建议。

目前，我正在尝试总结所有建议，以便我们能够前进，而不是停滞不前。

我明白了。
主要方案是在Windows上采用Unix用户。

过去，Unix用户在一个控制台中工作，而sudo本机地帮助他们在_same_控制台中以提升的权限进行工作。
以前，Windows用户会根据需要使用提升权限的控制台打开新窗口。由于在多窗口环境中很方便，因此这种方法可以很好地工作很多年。（考虑到Windows Core和Nano，Windows用户也可以从pssudo中受益）

因此期望是：

pssudo仅在交互式会话中有效
pssudo不会打开新控制台（Windows可接受UAC窗口，我们不想破坏Windows的安全性和实质性）
伪及时缓存凭证
pssudo不会为安全而缓存会话状态
所有平台上都使用相同的UX（尽可能）
pssudo运行本机命令
pssudo运行PowerShell脚本块/文件

实施细节：

PowerShell远程处理是大多数功能强大的解决方案。它已经实施并且可以工作。其他人也必须模仿此功能，才能在每个用户/每个会话/每个运行空间/每个作用域状态下执行PowerShell脚本块。
首选的传输方式是WinRM，因为所有Windows基础架构都基于WinRM。尽管MSFT不希望这样做，因为它基于SOAP，因此需要在WinRM中进行一些投资。
可以进行SSH传输。这仍然不是Windows的标准。实施和维护需要大量投资。支持旧系统存在一个问题。
其他传输方式，例如Unix套接字。不仅需要在基础架构上而且在PowerShell中也需要大量投资。

@ mklement0我想知道我在这里所做的事情通常都很出色:-)你抢了我成为对手的权利

iSazonov 于 2019-12-16

👍5 😄1

为什么不编写要求特权的Windows二进制文件，该特权使用传递给它的任何命令来启动Powershell实例。它必须是控制台模式的应用程序，才能正常工作。然后对于Linux，我们编写一个脚本，该脚本需要使用提供的命令来启动Powershell实例的权限。如果在实践中像理论上那样工作，那么将以提升的权限启动powershell，运行命令并退出。

minecraftchest1 于 2020-01-02

为什么不编写要求特权的Windows二进制文件，该特权使用传递给它的任何命令来启动Powershell实例。它必须是控制台模式的应用程序，才能正常工作。

原因是Windows API阻止了该操作，因此控制台应用程序将在新窗口中打开。我们已经讨论了可能的解决方法。

agowa338 于 2020-01-03

👍1

要记住的一件事是，无论如何实现，总是有一个过程往返于提升的过程之间。这意味着您将始终在管道中使用反序列化的对象，并且这些限制将适用。在很多情况下，这将不是问题，但是如果cmdlet需要活动的.NET对象，则它将无法正常工作。

为了通过SSH支持JEA，我们最终将需要一个通用的守护程序/服务，以替代WinRM作为该服务的需求。那时，我们将评估使用它来提升管道的一部分。

SteveL-MSFT 于 2020-01-07

👍5

仅供参考： https :

的GitHub
杰拉尔多格
适用于Windows的Sudo-在不跨越新控制台主机窗口的情况下提升运行-gerardog / gsudo

majkinetor 于 2020-01-30

👍2

仅供参考： https :
GitHub gerardog / gsudo Windows的

更好
http://blog.lukesampson.com/sudo-for-windows

的GitHub
杰拉尔多格
适用于Windows的Sudo-在不跨越新控制台主机窗口的情况下提升运行-gerardog / gsudo

Luke Sampson-Windows的Sudo
Windows版Sudo

Witchilich 于 2020-02-27

更好

没有。

Gsudo不会每次都提示输入密码，并且安装和使用速度明显更快。

majkinetor 于 2020-02-27

👍2

在我看来，不仅从这张票上的利益来看，应该接受这个问题（这意味着应该给它更多的时间和组织）。不正式承认它是一项工作任务是不正确的，因为如果没有积极参与就无法解决当前认为的技术难题。

我使用gsudo已有几个月了，我无法想象一直回到传统的Windows UAC。

majkinetor 于 2020-02-27

@majkinetor或在https://github.com/PowerShell/PowerShell/issues/11343中分离出此问题，以进一步讨论设计

SteveL-MSFT 于 2020-02-27

Powershell: 支持sudo<powershell cmdlet=""/>

重现步骤

预期行为

实际行为

最有用的评论

所有99条评论

更多细节

相关问题