Powershell: sudoをサポートする<powershell cmdlet=""/>

ハム！ とても興味深い。 しかし、実際の動作は予想通りだと思います。 Windowsと同様に、sudoのようなコマンドはありません。
ただし、「sudo powershell」を使用してから、（「sudo powershell」を使用して作成された）foo.txtを削除すると、Remove-Itemを使用したときに機能します。 もちろん、昇格されていない権限では機能しません。

PowerShell内からのLinuxコマンド（ "sudo nautilus"）では「sudo」のみを使用します。

:)

Windowsでも、別のユーザーまたは昇格されたユーザーとしてコマンドレットを実行する同様の機能と、ポータブルスクリプトで信頼できるものがあると便利です。 これにはRFCが必要な場合があります。

この機能は、＃3506を回避するのに役立ちます。

これが解決されない場合、これはLinuxを適応させるためのブロッカーになります。 sudo bashは許可されておらず、同様にsudopowershellも実行できません。

Maximoに同意します。sudoをbashに任せて、期待される機能の足場としてsudoを使用してPowerShellで昇格を行うための新しいコマンドレットを作成する必要があります。

@dantraMSFTはこれを調査していますが、ダンはこれに関する現在の考え方についての最新情報を提供できますか？

@pixelrebirthあなたが期待することについてもっと詳しく
いくつかの使用例も役立ちます。

@dantraMSFT議論のために、コマンドレットのような新しいsudoを呼び出します：Invoke-Elevated
これがsudoの仕組みであり、PowerShellの方法でInvoke-Elevatedに変換されます。

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

この例では、スクリプトブロック内のすべてが昇格して実行され、昇格されていないGet-SomeCmdletにパイプされます。
Credは、別のユーザーまたは昇格したユーザーとしての自分である可能性があります（sudoersファイルがホワイトリストとも呼ばれるように許可をどこかに保持する必要があります）

Invoke-Elevatedが実行されるインスタンスでは、デフォルトでロギングを有効にする必要があります。
ユーザー| コマンド| DateTimeまたは同様の形式のログ

たぶんこれのいくつかは後で拡張または変更されますが、これは私のブロッカーを削除するものです

また、次のように機能するはずです。

Get-ChildItem ./test | Invoke-Elevated -command {Remove-Item -force}
資格情報が現在のユーザーであり、パスワードを要求するだけの場合...

この例では、Get-ChildItemは昇格されていません。Remove-Itemは昇格されています。

私は今日、コミュニティの電話でこれについて尋ねていましたが、私の妻はそれに対する課題の説明中に怪我をし、私はそれをたくさん逃しました。 上司に伝えられるように、ここにメモを入れていただけませんか。

私は可能な限り助け、必要なところならどこでも圧力をかけます。

@pixelrebirth彼女が大丈夫だといいのですが！ 翌日か2日以内に通話の録音を作成するので、必要に応じて追いつくことができます。

基本的な要約は、 @ dantraMSFTが初期調査を行って、これをハッキーではない方法で行う方法をsudo powershell -c "invoke-foo"を実行できますが、それは明らかに機能しません。

@dantraMSFT ：調査を進めながら、ステータスを投稿して、さまざまなアプローチとのトレードオフを全員が確実に理解できるようにしますか？

当たり前のように思えるかもしれませんが、sudoソースコードを見て、それらがどのように管理しているかを確認してください。おそらく、低レベルのコーディングが必要です。 コードをより深く理解していただければ幸いです。

彼女は大丈夫です、彼女は彼女の手術の腰に感じます。 これについての迅速な対応に感謝します。 私はちょっとしたハックの回避策に取り組んでいます。それをやめたらここに投稿します。

@pixelrebirth参考までに、sudoはsetuidビットを使用します。詳細については、 //unix.stackexchange.com/a/80350/86669を参照してください。 ただし、シェル全体に設定するのはおそらく悪い考えです。

ネイティブWindowssudoが必要です（したがって、Powershell経由でのみ使用できるオプションは受け入れられますが、問題はおそらくここには属していません）。 私は最初からPowershellを使用しており、上記のInvoke-Elevated （または私が毎日使用しているもの）のように、99種類のsudoスクリプトを見てきました。 そのようなコマンドレットをPowershellに含めることは一歩前進ですが、Linuxでこれがどのように機能するかに関して、それらはすべて厄介だと感じています。

私にとって厄介なことの1つは、Powershell / Windowsに実装してほしい新しいシェルウィンドウ（Linuxではない）を開始することです。これがWindowsで技術的に可能かどうかはわかりません。

Windowsで使用できる可能性のある別のコマンドレット（ "Invoke-Elevated"）のアイデアは気に入っていますが、highで実行するスクリプトを作成する必要がある場合は、PowerShellを「sudo」で開くことに固執しない理由がわかりません。特権？

特に、タスクを自動化する場合は、いずれにせよ、ある種の高特権の資格情報を使用して実行するように最終的にスケジュールされます。
:)

それは典型的なワークフローではないからです。 あなたは「sudo」ではなく、永遠にそこに住んでいます。あなたは特定のコマンドをsudoし、非sudoの世界に住んでいます。 Windowsでこれを行う簡単な方法はなく、PowerShell自体の起動は非常に遅く、特にプロファイル要素がほとんど含まれていません。

典型的な毎日のセッションでは、特定のコマンドを20回実行し、他のコマンドは特権なしで実行します。 それがsudoの要点であり、必要な場合にのみ特権を上げることであり、頻繁に必要になる可能性があります。

私のワークフローは、コマンドを実行すると、特権について文句を言います。私はsudo -Lで、最後のコマンドを特権で再度実行します。 poshの起動は非常に遅いので、adminシェルを起動して常にそこに住んでいますが、明らかに良い考えではありません。

ありがとう@majkinetor！
:)

sudoは、UACプロンプトのCLIバリアントである必要があります。 最近まで、WindowsはCLIに対応していませんでしたが、今ではこれが必要だと思います。 シェルだけで100％Windowsのことを実行できる時が来ました-私は個人的にシェルとブラウザだけを使用し、他にはほとんど何も使用していません。

@majkinetor ：私の知る限り、昇格されたプロセスを起動する唯一の方法は、UACプロンプトを使用することです。
FWIW：ShellExecuteExを使用すると、PowerShellを変更せずにWindowsでこれを実行できます。
ただし、結果をストリーミングバックすることを期待している場合は、 それは非常に異なる話です。

私の知る限り、昇格されたプロセスを起動する唯一の方法は、UACプロンプトを使用することです。

特定のアプリをUACから除外することができます。これは、独自の方法で昇格を処理すると思います。

Windows上のSudoのソリューション/回避策を提供したかった。 フィードバック/批評は大歓迎です。 このようなことをここに投稿するのが適切でない場合は、事前にお詫び申し上げます。

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

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

Sudoモジュールには3つの機能があります。

• 新規-SudoSession
• 削除-SudoSession
• 開始-SudoSession

Start-SudoSession（別名「sudo」）は、昇格する必要がある1回限りのコマンド用です。 コマンドを実行する前に、資格情報の入力を求められ、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-昇格されたコマンドを挿入できるElevatedPSSessionを開く場合はSudoSession。 昇格を必要とする複数の操作を含む長いスクリプトでは、最初にElevatedPSSessionを作成し、UACプロンプトを1回受信してから、必要に応じて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プロンプトが表示されます。 したがって、合計で、特定のスクリプトで任意の数の昇格された操作を実行するには、2つのUACプロンプト（1つはElevatedPSSessionを開くため、もう1つはそれを閉じるため）でのみヒットします。 削除-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コマンドレットを使用して昇格されたPSSessionを作成します

• ElevatedPSSessionの-Expressionパラメーターに渡された式を実行します

• 昇格されたPSSessionを削除し、ローカルグループポリシーとWSMAN / WinRM構成に加えられたすべての変更（存在する場合）を元に戻します。

編集：Remove-SudoSessionの例のタイプミスを更新しました。

@pldmggあなたのコードがどのライセンスの下にあるのかわからないので、あなたが何をしたのかさえ見ることができません。 LICENSEファイルを追加できますか？ MITは最も友好的であり、コードを使用したり、コードから派生させたりすることができます。 ありがとう！

@pldmgg @ SteveL-MSFTが述べたことのフォローアップとして、このプロセスを支援する優れたガイドはhttps://choosealicense.com/です。

tl; dr-次のライセンスで間違いをです。

• Apache 2.0
• MIT

詳細

Apache 2.0には、MITに比べていくつかの追加の長所がありますが、全体として、それらは非常に寛容であり、他のオープンソースライセンスで簡単に使用でき、非常にビジネスフレンドリーです。 コピーレフトライセンス（GPL）を選択した場合、他のツールがGPLライセンスに移行しない限り、コードを他のツールで使用することはできません（ウイルスライセンスとも呼ばれます-ここではLGPLは例外であり、LGPLライセンスのモジュール/バイナリは他のコードへのライセンス変更を必要とせずに、他のツールの隣に配置されます）。

@pldmggも、とても、とてもかっこいいです！

@ferventcoder参照をありがとうhttps://choosealicense.com！ 皆さん（+ @ SteveL-MSFT）がおそらく疑っていたように、私はどのライセンスを選ぶべきか本当にわかりませんでした。 その他のpowershellリポジトリ全体をApache2.0を使用するように更新し、Sudo.psd1をApache 2.0を参照するように更新しました（gitリポジトリとPowerShellギャラリーで）。 これが人々に役立つことを願っています！ すべてのアドバイス/批評を歓迎します！

@ SteveL-MSFTライセンスがApache2.0の場合、使用できますか？ MITにする必要がある場合は、お知らせください。更新します。

@pldmggソリューションに関する私の最大の問題は、CredSSPの使用です。 これは資格情報を処理するための安全性の低い方法であり、UACの境界に多くのリスクをもたらすと思います。

Powershell Magaizeから引用するには、

「CredSSPを使用して、ドメイン管理者アカウントを使用してユーザーのワークステーションを認証することはお勧めできません。基本的に、王国に鍵を渡すことになります。」

「信頼性の低いコンピューターに信頼性の高い資格情報を配置しないでください」

UACの要点は、コンピューター上のアプリケーションを信頼しないことです。 自分のマシンで大混乱を引き起こすsudoコマンドに同意する場合でも、通常は資格情報がありません。 sudoコマンドがドメイン資格情報に明確にアクセスできるようになった場合、ネットワークを危険にさらす可能性がはるかに高くなります。

CredSSPなしでソリューションを機能させることはできますか？ そうでない場合、CredSSPを使用してどのような問題を解決しようとしていましたか？ この情報は、PowerShellチームがより安全なソリューションを見つけるのに役立つ可能性があります。

@pldmgg Apache2.0で十分だと思います。 ありがとう！

@ dragonwolf83これは一般的な懸念事項です。 私は実際に、このスレッドのこの特定の状況では問題ないという私の議論全体を発表しました：

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

しかし、要約すると、ここでは問題ないと思います。理由は次のとおりです。

• ローカルホストに接続しています（リモートではありません）

• Windows 8.1 / Server 2012R2以降、CredSSPはパスワードをクリアテキストで送信しなくなりました

• リモートデスクトッププロトコルは、CredSSPと同様に、パスザハッシュ攻撃に対して依然として脆弱であるため、CredSSPの場合と同様に、RDPの場合も同様に心配する必要があります。 （もちろん、RDP制限付き管理者モードまたは新しい「資格情報ガード」があります）

PSこの記事は、PowerShell Securityのgotoリファレンスになりました（ここで、Credential Guardについて学びました）。強くお勧めします。

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

6.0.0の場合、最終的には次のようになります。

Linuxにのみ存在するsudoと呼ばれるスクリプト関数（Windowsの昇格のサポートは延期されています）。 引数がコマンドレット/スクリプトブロックの場合、それらの引数を使用してPowerShellをsudoします。 これは、今のところ、オブジェクトのパイプライン化が機能しないことを意味します。 引数がネイティブコマンドの場合は、それをsudoに直接渡します。

6.0.0以降、最終的には次のようなエクスペリエンスを実現したいと考えています。

Get-Item foo.txt | sudo Remove-Item

WindowsとLinuxの両方で動作します。 cc @joeyaiello

@ PowerShell / powershell-committeeの議論に基づくと、これは6.0.0では必須ではなく、 Invoke-AsUserタイプのコマンドレットに投資することをお勧めします。

一般に標高を変更するには、UNIXでsetuidビットを使用するものが必要であり、それ自体がsudoになります。 sudoは、簡単にエミュレートできない特別なバイナリであり、セキュリティのためにエミュレートしないでください。 実際のsudoを使用して、問題のコマンドを実行するPowerShellの一時インスタンスを起動してください。 また、リモートサーバーでシェルが開いていることを忘れる可能性があることを考えると、シェル全体をsudoすることはかなり危険です。 sudoには、ユーザーが数分後に昇格したことを忘れるメカニズムがあり、長期的にはマシンを保護します。 この問題の解決により、より多くの人がLinuxサーバーの本番環境でPowerShellを使用できるようになります。 現状では、本番環境ではセキュリティが最優先事項であるため、PowerShellは副次的な目新しさのままです。

今日の@borgdylanでは、PowerShell Core内でsudo pwsh -c foo実行できます（またはsudo nativecmd ）。 既存のPowerShellCoreセッション内でコマンドレットをsudoできるようにすることが望まれていると思います。 ここではsudoを再現しようとはしていませんが、使いやすくするために構文上の糖衣構文を使用しています。

＃1527とこの問題がマイルストーンにどんどん押し戻されているので、私は疑問に思い始めています。管理者の作業を行うためにルートセッションにログインするのは本当に快適ですか？ PSが何らかの形で関与している場合、PowerShellコマンドを呼び出す便利な方法は事実上ありません。

@MathiasMagnusこれは完全にはテストしていませんが、sudoでパスワードを必要としないように、一般的なコマンドまたは繰り返し使用されるコマンドを構成できます。 テストするために、これをvisudoで追加しました。

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

その後、PowerShellSSHリモーティングセッションを介してsudo pwsh -c 'cat /etc/sudoers'を呼び出すことができました。 セキュリティをどのように行っているか、およびsudoersで何を正確に構成しているかに応じて（たとえば、 All=(ALL:ALL)は少しオープンです...）、これは安全または危険な場合があります。

Linuxにsshする場合（つまり、PowerShell SSHリモーティングの代わりにbashシェルに）、私が知る限り、pwsh内で通常のパスワードプロンプトを使用してsudoを実行できます。

それは不可能なほどではなく、現在の回避策には手荷物が含まれているだけです。

@ MathiasMagnus ＃1527は、適切な回避策がないため、引き続き6.1.0を対象としています。 コマンドレットの場合、主な問題は、sudoされたコマンドレットとの間のパイプライン化の複雑さです。 単一操作の場合、 sudo pwsh -cが実行可能です。 もちろん、コミュニティの誰かがPRを提出した場合、私たちはそれを喜んで受け取ります。

Windowsでは、これはssh接続を昇格しないと解決できないと私が思う

物事が機能せず、行動を起こさないことを簡単に理解できることは知っていますが、私の専門知識は他の場所にあります。 私は主にC ++とGPGPUライブラリに貢献し、Vcpkgは多くのCMake移植を行っています。 私はC＃を書いたことがなく、書く能力がないと思います。 ただし、私は最大12台のマシンの小さなクラスターを管理しています。 手作業で管理できるという境界線上にありますが、sudo機能がひどく欠けています。つまり、Ubuntuでrootユーザーのログインを作成するつもりがない場合、これは嫌なことです。 DSC Coreは解決策になるでしょうが、1年前に発表されたとしても、最近は無期限に延期されています。

Linux上のPowerShellCoreは、現在のところ、自動化された方法とLinuxのシステム管理者に馴染みのあるアドホックスタイルの間に少し立ち往生しています。 誰かがこの問題に参加する時間を見つけてくれることを願っています。

@MathiasMagnusこれは誰もが望んでいることですが、解決するのは簡単な問題ではありません。 ネイティブコマンドに対してsudoを使用すると正常に機能することに注意してください。実際には、コマンドレットに対してsudoを実行することはできません。 回避策は、pwsh内でpwshを呼び出すことです。

sudo pwsh -cremove-item何か

主な問題は、パイプライン内の何かである場合です。

get-item foo * | sudoremove-item

@ SteveL-MSFT少なくとも概念はそれほど複雑ではありません。 ご意見をお聞かせください。

すべてのケースを処理するには、sudo、su、loginバイナリの組み合わせが必要です。

それはする必要があります：

• コールバック用のUNIXソケットを作成し、宛先ユーザーのみにそのソケットへのアクセスを許可します。
• 呼び出し元にsudoアクセスが許可されていることを確認します（ su 、 sudo 、 loginのソースコードをコピーするだけでよいと思い
  
  
  
  • / etc / sudoersが存在する場合は、解析する必要があります
    
    
    
    
    
    • 特定のコマンドのみ
    
    
    
    • 宛先ユーザーのパスワードを使用する
    
    
    
    • 資格情報を検証せずに（パスワードなし）
    
    
    
  
  
  • そうでない場合は、pemを呼び出して、ユーザーがユーザーrootの資格情報を直接「知っている」かどうかを確認する必要があります。
  
  
  • 宛先ユーザーの資格情報もわからない場合は、アクセスを拒否し、PowerShellで例外をスローします。
  
  
• 検証に合格した場合は、ユーザーコンテキストをルートユーザーまたは宛先ユーザーに切り替える必要があります。
• ユーザーコンテキストを切り替えたら、新しいプロセスは、UNIXソケットに接続することにより、実行中の元のPowerShellへの通信を確立する必要があります。
• ユーザーが「exit」と入力すると、unixソケットを介して終了したことを通知し、終了すると、ユーザーは自動的に呼び出し元の特権に戻るため、プロンプトを表示したり、次を実行したりするために必要なのはホスティングPowerShellだけです。命令。
• 代わりに、ホストのPowerShellが終了すると、UNIXソケットが閉じられ、ターミナルを閉じる場合と同様に、昇格されたPowerShellが実行を停止して終了する必要があります。

実行フローは次のようになります。
PWSH（ソケット/proc/self/change-user.socketを作成します）=> PWSH-SU（ソケットと宛先ユーザーをパラメーターとして呼び出します。PWSH-SUはroot自体として実行するようにsuidに設定されます）=>宛先ユーザーが接続するときのPWSH UNIXソケットに。

最も時間のかかる部分は、PowerShellがUNIXソケットを介して内部的に接続できるようにすることです。 パイプを呼び出すときに文字列だけでなくオブジェクトを処理するため、他のUNIXアプリケーションが行う入力リンクと出力リンクをリダイレクトするだけでは不十分です。

なぜ3つのバイナリすべてを使用するのですか？
sudoは、複数のユーザーが監査機能を失うことなくルートコンテキストに切り替えられるようにするために必要です。
suは、宛先ユーザーの資格情報を使用して他のユーザーに切り替えるために使用されます。
loginは、まったく新しいログインセッションを作成するために使用されます。
これらの機能をすべてPowerShellにも含めると、1つしかない場合と比較して、多くの場合に役立ちます。

パイプを使用すると、Windowsでもこれが驚くほど便利ではない方法で機能する可能性があります。すべての「sudo」スクリプトとUACをクリックして別のシェルを取得するのは嫌ですが、このようなパイプを使用すると、同じシェル内で実行できます。すでに管理者として実行されている別のインタープリターとパイプを介して通信し、実際のsudoのものを実装することによるLinuxのように（たとえば、プロンプトタイムアウト、またはカスタムPowerShellエンドポイントの代わりにコマンドを使用したsudoersファイル）

これについての考えを見て本当にうれしいですが、実際の実装に関しては、私たちは自分たちより少し進んでいるように思えます。 まず、システムには、昇格されていないプロセスから何であれ、昇格されたプロセス、スレッドを作成する方法が必要です。 UACを経由せずに、PowerShellの昇格されたインスタンスを最初に作成できない場合、コマンドレットの懸念は真に解決できません。 IMO、ここで対処する最初のシナリオは次のようになります-SSHセッションが制限されています-管理者権限で通常のexeをどのように実行しますか？

私はここでこれを実験し始めrunasが資格情報プロンプトを使用して昇格されたプロセスを作成できるようにするのと同じくらい簡単ですが、最初のステップがなければ、これはすべて理論的です。

UACを経由せずに、PowerShellの昇格されたインスタンスを最初に作成できない場合、コマンドレットの懸念は真に解決できません。

これを行う1つの可能性は、オプション「最高の特権で実行」を指定してスケジュールされたタスクを使用することです。

ええ、でもそれを作成するには、すでに管理者権限が必要ですか？ それがpsexecが行うことです。 私の知る限り、今のところ、ある時点でUACを通過する必要があります。 その変更を確認したいのですが、すべてのSSHセッションが昇格しているため、セキュリティ上の懸念があります。 大ざっぱなソフトウェアがWindowsマシンにSSHで接続しようとした場合、たとえば、秘密鍵が設定されている別のコンピューターから（またはループバックシナリオ）、必要なことは何でも実行できます。

@parkovski私のソリューションはLinux / MacOSと他のすべての*
sudoは現在Windowsにも存在しないため、私にとってはこの問題の範囲外です。

また、UACの問題を解決するために、Windowsは将来的にSUIDとGUIDを実装する必要があります。 他のすべては、長年の問題に対する単なる汚い回避策です...

ええ、でもそれを作成するには、すでに管理者権限が必要ですか？

そうですが、UACポップアップはトリガーされません。

UACは、Microsoftのアプリケーション互換性ツールキットを使用して公式の方法でスキップすることもできます。

WindowsはSUIDとGUIDをサポートしていません。

Windowsはそれをサポートする必要はなく、そのOSでは概念が無効です。
そのアクセス許可モデルはACLに基づいており、単一のグループ所有権はありません。

また、Windowsで完全なsudoレプリカである必要はなく、管理コマンドを呼び出すためのより使いやすい方法です。

Windowsユーザーはおそらく今日昇格されたPowerShellセッションを開くことに慣れているのに対し、Linuxユーザーは必要に応じて非rootおよびsudoとして実行することを期待しているため、Windowsサポートを延期することは問題ないと思います。 設計によって将来のWindowsサポートが妨げられないようにしたいだけです。 また、任意のユーザーではなく、rootに対してsudoを有効にして単純化することに焦点を当てるでしょう。これは、使用量の90％以上であると思います。

@ SteveL-MSFT

また、任意のユーザーではなく、rootに対してsudoを有効にすることに焦点を当てるでしょう。

これは大きな違いにはならないと思いますが、ユーザーコンテキストをrootに切り替えることは他のユーザーに切り替えることとほぼ同じであるため、上記で概説した要約に完全なsu / sudoエクスペリエンスを提供します。

Windowsユーザーはおそらく今日昇格されたPowerShellセッションを開くことに慣れているので、Windowsサポートを延期するのは問題ないと思います。

私が一緒に働いた人々の大多数は、可能であればUACを無効にするだけです。

残念ながら、これは多くの環境では実際にはオプションではありません。MSがUACを完全に廃止するのではないかと、私は非常に疑っています。 😕

この問題はUACに関するものではありません。 しかし、私の観点からは、それは完全に捨てられ、厳密な2つのアカウントに置き換えられる必要があります。 * NIXと同じ概念で、ユーザーとして開始し、sudoとSUID / SGID-Flagsを使用して必要に応じて昇格します。

最近、 $profile以下を追加しました。 https://stackoverflow.com/a/56265080/118098で詳しく説明しました

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

少なくとも一見すると、これは私にとってはうまくいき、「sudo"。これは、 https： //github.com/PowerShell/PowerShell/issues/3232#issuecomment-354853084による「既存のPowerShellコアセッション内でコマンドレットをsudoできる」場合には適用されません。

ただし、呼び出し元のコマンドのセッション全体を昇格されたコンテキストに与えることがどれほど重要か疑問に思います。 他のシェルでは、 sudoは、提供されたコマンドを新しいコンテキストで実行します。

Windowsで管理者としてコマンドを実行するのに適した基本的なsudoを実装しました。 「RunAs」がこれらのプラットフォームで正しく昇格するかどうかわからないため、これがlinux / macでも機能するかどうかはわかりません。

プロファイルを編集します。

PS > notepad $PROFILE

次のsudo関数を追加します。

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

次に、シェルで呼び出します。 コマンドレット、実行可能ファイル、通常は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これは、GUIが利用可能な場合に役立つ回避策であり、当面は役立ちますが、GUIにアクセスしないと機能しないため、これは実際のsudoではありません。 リモートシェル（ssh）では、文字通り、これを機能させる唯一の方法は、ここで説明しようとしたサービスとクライアント

いくつかの一般的な提案に対処するために、私はすべての可能性を見てきました。

• UACを無効にすることは解決策ではありません。 これは個人的な選択として行うことができる回避策ですが、この問題の一般的な解決策ではありません。
• UACをポップアップするもの（私が見たすべての「sudo」スクリプト）は、昇格されたリモートセッションを開始するために一度実行することを含め、解決策ではありません。
• GUIを_まったく_必要とするものはすべて解決策ではありません。 ここでsshを使用していて、GUIが使用できないと仮定します。
• Windowsに大きな変更を加える必要があるものは、解決策ではありません。 UACがより良いものに変わることを期待することはできません。
• UACが高に設定されていると機能しないため、Microsoftの署名付きバイナリでさえ解決策ではありません（wsudo readmeでこれを間違えました。後で修正します）。
• Windowsでのsudoの唯一の実際の解決策は、認証が成功したときにユーザープロセスを昇格させるサービスです。 他のアイデアも聞きたいのですが、まずは調べてみてください。

基本的に、誰かが多くの仕事をしなければならず、それを回避する方法はありません。 私たちが望んでいるのは、PowerShellがUnixでこれをサポートすると、Windowsでの代替品のドロップであり、sudoが機能することを期待するとおりに機能するものです（GUIなし、UACなし）。

最初にこの問題の範囲を明確にしていただけますか？ 現在、複数の人がさまざまなトピックについて話していると思います。
この問題ですか：
a）Linux / MacシステムのPowerShell内にsudoを実装することについて？
b）sudoレプリカをWindowsに実装しますか？
c）psremoting時に特権を昇格させることを許可しますか？
d）Windowsで他のユーザーになりすますことを許可しますか？
e）非特権ユーザーアカウントから特権ユーザーアカウントへの切り替えを許可しますか？
f）まったく違うもの？

a）https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067
b）と同じ（windowsにもunixソケットがあります）が、suidバイナリの代わりに、サービス（「オペレーティングシステムの一部として機能する」特権を持つユーザー内で実行されているユーザーシステムなど）によって生成される必要があります。そのサービスも特権をチェックする必要があります。 または、WindowsにSUID / GUIDの概念を実装します。
c）必須ではない場合、リモート処理時にすでに最高の権限を持っています。 リモートホストにアクセスする場合、特権の分離はありません（このように機能するローカルホストループバックUACバイパスもすでにいくつかあります）。
d）a / bからのアプローチも採用できますが、ユーザーの資格情報を知らないか、新しいWindows / ActiveDirectory認証バックエンドを作成せずに、ネットワークリソースにアクセスしようとしたときにどのように機能するかわかりません。
e）bと同じですが、資格情報のチェックも必要です。あるいは、runas apiを緩めて、ユーザー名とパスワードを知っている人が新しいユーザートークンを取得し、そのプロセスを制御できるようにすることもできます。 （UACのセキュリティの概念と考慮事項を検討する可能性は低いため、bに戻ります）。

IMOこの問題は、基盤となる機能がすでに存在するPowerShellにsudoを実装することに関するものである必要があります。 このターミナルの問題では、Windowsと同等のsudoについての議論がおそらくより適切です。

このターミナルの問題では、Windowsと同等のsudoについての議論がおそらくより適切です。

CLIの世界への唯一のフロントエンドであるにもかかわらず、ターミナルアプリがsudoについて議論するのに適した場所であるのはなぜですか？ 同じロジックで、ConEmuリポジトリにチケットを提出できます。

IMOこの問題は、基盤となる機能がすでに存在するPowerShellにsudoを実装することに関するものである必要があります。

次のPowershellのポイントの1つは、それを使用するシステム間の互換性の問題が少ないことです。 それに関して、システムXでのみ何かを行うことはIMOでは受け入れられません。

CLIユーザーとしての私は、 sudoがsudersファイルまたはいくつかのウィンドウを同様に使用する本格的なLinux sudoである場合、それほど気にすることはできませんでした。 Sudoは、OSの昇格機能への単なるインターフェースです。 このようなインターフェースは、「バックエンド」に関係なくほぼ同じように機能させることができます。

それ以外の場合、GUIスタンドに関する@parkovskiのポイント-理由の中に

CLIの世界への唯一のフロントエンドであるにもかかわらず、ターミナルアプリがsudoについて議論するのに適した場所であるのはなぜですか？ 同じロジックで、ConEmuリポジトリにチケットを提出できます。

そのレポは単なる「ターミナルアプリ」ではないからです。 それを実行するチームは基本的にWindowsのテキストモード部分を所有しており、時間を見つけることができればsudoの実装に興味があるとすでに述べています。 一方、PowerShellチームやConEmuの誰も提供していません。

ここでWindowssudoが範囲外であると思う理由は、正しく実行することはかなりの量の作業であり、PowerShell自体に直交しているとすでに判断しているためです。 PowerShellは、存在する場合にそれを使用できますが、実際には特定のシェルから独立したコンポーネントです。

一方、PowerShellがsudoバイナリを介してコマンドレットを実行できることは、プラットフォームやそのバイナリが実際にどのように機能するかに関係なく、完全にここに属するPowerShellの一部である必要があります。

CLIユーザーとしての私は、sudoがsudersファイルまたはいくつかのウィンドウを同様に使用する本格的なlinux sudoである場合、それほど気にすることはできませんでした。 Sudoは、OSの昇格機能への単なるインターフェースです。 このようなインターフェースは、「バックエンド」に関係なくほぼ同じように機能させることができます。

うん、絶対にそうすべきだ。 sudoがWindowsにまだ存在せず、多くの作業が必要であり、PowerShellチームによって作成されることはおそらくないというだけです。 そのようなものが存在する場合、PowerShellがWindowsでも機能するようにこれを実装することを期待しましょう。

とにかく、この問題はさまざまな方向に進んでいるので、ここで正式な回答が得られるまで、コメントを延期します。

これについて何か意見はありますか？
http://blog.lukesampson.com/sudo-for-windows
scoop install sudoでインストールされ、私が考えることができる最も近いものです。 これはunixsudoのように機能します-標高を指定してコマンドを実行します。 私はすべてのユーザーのためにpipまたはInstall-Moduleでそれを使用します。

Luke Sampson-Sudo for Windows

Sudo for Windows

@ Restia666Ashdoll名前がInvoke-ElevatedCommandに変更された場合は、問題ありません。
これは、sudoがコマンドの昇格だけでなく、ユーザーのなりすましや特権の「ドロップ」（ sudo -u nobody command ）にも関与するためです。 また、既存の名前を再利用することは、特に機能とパラメーターが異なる場合は、悪い考えであることがすでに証明されています。
偽装を伴う真のsudoがどのように見えるか、そしてそれがどのように機能するかについては、すでに上記で概説しました。

@ Restia666Ashdollこのスレッドでこのコメントを読んでください。

@parkovskiこれは、-Verb RunAsのラッパーであり、いくつかのコマンドでのみ機能します。 私がリンクしたものは、ほとんどすべてで使用できます。 たとえば、私は次のように使用します- sudo pip install httpie 。

あなたは私の投稿を読んでいませんでしたか？

タイトルを編集して「NOTASUDO ON WINDOWSDISCUSSION」のようなものを含める方法はないと思いますか？ 私は個人的にこれに答え続ける義務はないことを知っていますが、人々は彼らの研究をせずに同じことを言って現れ続けます。

この男の購読解除リンクをクリックしようとしましたが、残念ながら、彼としてログインしないとそれができません。

@troymooreをGitHubに報告し

ここでお話ししたことのない、ユニークで異なるソリューションを提案したいと思います。 名前付きパイプのようなものを使用して、コマンドを昇格されたプロセスにシリアル化し、シリアル化された出力を呼び出し元のプロセスに返すのはどうですか？

これがNTでどのように機能するかを示す機能モジュールは次のとおりです： https ：

もちろん完璧ではありませんが、別のコンソールを開かなくても、簡単なタスクやパイプラインを上げることができます。 sudoのデザインのクローンを作成することが長期的な最善の解決策になるとは思わないので、これをsudoに似たものとして売り込むつもりはありませんが、このあいまいな標高の問題に対する別のアプローチがさらに建設的な議論になるかもしれないと思いました。

編集：私も言及する必要があり、これはUACless上昇のため@parkovskiの要求を達成することはありません。

JEAのようです。
シリアル化に関しては、すべてのモジュールがこれをサポートしているわけではありません。

JEAのようです。

はい、それがアイデアです。

シリアル化に関しては、すべてのモジュールがこれをサポートしているわけではありません。

おそらくコードで見たように、これはパイプのもう一方の端でコードを再構築するテキストストリームで軽減されます。 これは遅いことは認めますが、それでも新しい回避策です。 JEAについてのあなたの言及は、ここでも影響力のある要因でした。 コードの一部を昇格する必要がない場合は、昇格する必要はありません。

このモジュールは、NT上のGUIセッション内でインタラクティブコマンドを昇格させるという非常に特殊な問題を解決することを目的としています。 ネイティブsshがNTのものであると誰もが想像する前に、このことは5年前のように始まりました。 これはNTが標高を処理する方法に関連する問題であるため、 @ parkovskiに同意します。

それでも、PowerShellが任意の形式のコマンド昇格をサポートする前にsudoのような実装がNTに存在する必要があるという涅槃の誤りによって止められる代わりに、シェルセッション内で最初に任意の形式のJEAインタラクティブ昇格をプッシュしませんか？

これは、少なくともNTの世界でのセキュリティ慣行の改善を促進するでしょう。 インタラクティブに実行するコマンドレットと、別のコンソールセッションを開始するコマンドレットの両方を実装してみませんか？ またはさらに良いことに、さまざまなユースケースを持つより質素なコマンドレットのセットと一緒に昇格されたセッションを開始する現在の方法を宣伝するだけですか？ それは少なくとも一歩前進です。

また、Pythonelevateライブラリでさえこのモジュールが行うことを実行できないことを付け加えるかもしれません。 まだ動作しない別のモジュールを見つけましたか？ 私の主なポイントは、おそらく私よりも賢い人がこのモジュールとそのア​​イデアを取り入れて、NTに適した方向に実行できるということです。 その後、NTと* nixのプラットフォームの始まりが途中で出会う可能性があり、PowerShellのより一般的な実装を改訂してコマンドを昇格させることができます。

少なくとも私の2セントです。 しかし、コードを見て、中のアイデアが良くないと感じたら、私は理解します。 私はまだ誰もこのようなことを試みているのを見たことがありませんでした。

（a）はい、これは非常に難しい問題であり、（b）MSによってのみ適切に解決できるため（オープンソースではないため、Windows）、sudoのポイントを説明するという私の欲求不満の悲しみから少し離れます。 （c）他の人もこれに情熱を注いでいるのを見るのは本当にクールです。

私はその道を歩み始めたので、これを適切に行うことがどれほど難しいかを知っています。 したがって、今のところそれを妨げているのがUACダイアログだけである場合は、そうしてください。 少なくともこの方法で、わずかな労力でクロスプラットフォームソリューションをテストできます。

私が個人的にPowerShellに期待しているのは、Unix sudoの包括的なサポートですが、現在および将来の潜在的な実際のWindows sudoとして、何らかの形式の「pseudo-sudo」スクリプトをサポートするように設計されています。 私の考えでは、誰かがWindows sudoが最終的にどのように機能するかをプロトタイプ化しても、UACの制限を残した場合、それはかなり簡単で、基本的に今のところと同じくらい良いものを提供し、本物を手に入れたらきれいになるはずです。ただのドロップイン代替品です。

明らかに、これは、誰かがUnix uid / gidモデルとWindowssid / aclモデルの両方を理解するか少なくとも変換するモデルを考え出す必要があることを意味します。 うまくいけば、この人は挑戦が好きです。 これを推測するには、MS内の端末およびWindowsセキュリティチームとの話し合いも必要になります。

多くの人が独自のベストエフォートの回避策を作成しており、このようなものをサポートすることで、これを行うための堅牢な方法を設計するのに役立つと思います。

補足-これらの回避策スクリプトを作成する人は誰でも、sudoが持つタイムアウト機能を、ポップアップと同じくらい煩わしいと考えるかもしれません。

Start-Process pwsh -NoNewWindow -Credential $credについて考えることができます。 それは機能しませんが、可能です。

明らかに、これは、誰かがUnix uid / gidモデルとWindowssid / aclモデルの両方を理解するか少なくとも変換するモデルを考え出す必要があることを意味します。 うまくいけば、この人は挑戦が好きです。 これを推測するには、MS内の端末およびWindowsセキュリティチームとの話し合いも必要になります。

Unixにもaclsがあり、windowsにはposix互換性があり、少なくともドメインジョイントの場合は、使用できるプライマリグループ属性（およびposix属性）もあります。 ドメインに参加していないWindowsクライアントに実装する必要があるだけです（または今のところUserと想定されています）。

したがって、UNIXおよびWindowsのアクセス許可の一般的なモデルは基本的に次のとおりです。
所有ユーザーを持つACLと、いくつかの予想されるACE（ユーザー、グループ、その他）を持つ所有グループ。

UNIXのパーミッションを次のようにマッピングできるよりも：
uid =>所有者SID
gid =>オブジェクトを作成したユーザーのプライマリグループSID。
ユーザー=>作成者所有者IDS-1-3-0
グループ=>作成者グループIDS-1-3-1
その他=>世界/みんなS-1-1-0
UNIXのACLリストからのuidのマッピングは、システムがLDAP、Active Directory、またはその他のディレクトリの一部である可能性があることを考慮する必要があるため、少し複雑です。 PowerShellのスコープで検討する2つのケースは、ディレクトリなしとldap / activeディレクトリだけです。
最初のケースでは、S-1-6-1-uidとS-1-6-2-gidを使用することをお勧めします（S-1-6がまだ利用可能であり、担当チームがこの目的のためにそれを割り当てる用意があると仮定します） ）。
2番目のケースでは、認証バックエンドを介してuidを解決する必要があります。 ldap / active Directoryサーバーは、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 ：

Start-Process pwsh -NoNewWindow -Credential $ credについて考えることができます。 それは機能しませんが、可能です。

更新： .Net Core （およびWindows APIもそうだと思います）では、同じコンソールに接続された新しいプロセスを実行できません。

したがって、使用できる唯一の方法は、昇格されたWindowsサービスです。 ただし、安全を確保するには、「sudo」ごとにこのようなサービスプロセスを作成する必要があります。
したがって、解決策は、昇格されたユーザー資格情報を使用してローカルホストへのNew-PSSession（またはPSSessionで呼び出す）になります。

@iSazonov同じコンソールに接続できる唯一のものの1つは、ここですでに述べたものです： https ：

Windowsがunixソケットをサポートするようになったので、それらまたは名前付きパイプのいずれかを使用でき、特権サービスは資格情報の検証を担当し、常に実行する必要があります（* nix osesのリンクされた投稿で説明されているようにsuidを介して呼び出されるのと比較して） 。

たぶん、そのような認証API機能を提供するためにlsasを拡張する必要がありますか？
そうすれば、同じコンソールに安全に接続して入力を受け入れることができながら、完全な偽装を取得できます。

@ agowa338あなたの提案「事実上の」はPowerShellリモート処理です。 すでに実装されています。

だが

したがって、解決策は、昇格されたユーザー資格情報を使用してローカルホストへのNew-PSSession（またはPSSessionで呼び出す）になります。

ローカルホストでは機能しません。 AccessDeniedのみをスローします。

これらの1つを除いて、次の場合があります。

• UACはオフです
• 管理者承認モードを有効にせずにBUILDIN \ Administratorに接続しようとしました。
• プロセス（PowerShell）はすでに昇格しています。

これが@ jborean93による理由の良い説明https ：

したがって、ブローカーとして機能する特権サービスが必要であるか、APIの1つを変更する必要がありますが、これはPowerShell / PowerShell内で実行できることではなく、Microsoftの担当者から内部的に委任される必要があります。

@ agowa338参照したコメントは、ローカルのWindows APIに関するものであり、PowerShellのリモート処理に関するものではありません。

@iSazonov ：ローカルホストへのPowerShellリモーティングを試したことはありますか？ 私はそうしました、そしてそれは上に概説された理由のために働きませ

PowerShellをローカルホストにリモーティングすると、ローカルコンピューターで昇格された特権を取得できません。

ただし、PowerShellリモーティングは、ローカルホストを除くネットワーク内の他のすべてのホストに対して昇格された特権を付与します（ドメイン管理者などのメンバーであると想定）。

それは私たちが窓にsudoの同等物を必要とする理由です。 PowerShellリモーティングがそのように動作する場合は、機能がすでに存在するため、ドキュメントに例を書き込むことでこのチケットを閉じることができます。

@ agowa338セキュリティ保護のため機能しません。 OSの機能ではありません。 ドキュメントhttps://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshootingで説明されているようにWinRMを構成できます。 あなたが参照した問題は、これがSSHで機能することも示しています（手順はそこの記事で参照されています）。

機能がすでに存在するので。

リクエストは、「foo.txtがrootによって所有されているsudo Remove-Itemfoo.txt」を機能させることです。
それは機能しませんが、私たちは欲しいでしょう。
問題は、言語と実装の糖衣構文の2つの部分で構成されています。

提案について詳しく考えると、ユーザーごと、セッションごと、実行スペースごと、スコープごとのPowerShellコンテキストが必要であることがわかります。 次に、セキュリティコンプライアンス要件に対処する必要があり、デフォルト構成で「アクセス拒否」が発生します。 その後、提案は、すでに実装されているPowerShellリモート処理と同じになります。

about_Remote_Troubleshooting-PowerShell

セキュリティ保護のため、機能しません。 OSの機能ではありません。 ドキュメントの説明に従ってWinRMを構成できます

@iSazonovもう少し詳しく説明していただけますか？ そのマシンにリモートで接続したり、ネットワーク内の任意のマシンから他のマシンにリモート接続したりできますが、いずれのマシンからローカルホストにもリモート接続できません。 そして、はい、私はそのページを読みました。

リクエストは、「foo.txtがrootによって所有されているsudo Remove-Itemfoo.txt」を機能させることです。

Windows以外のシステムの場合、UNIXソケットアプローチを使用して、PowerShellリモーティングの偽装/昇格を実装できます。

もう少し詳しく説明していただけますか？ そのマシンにリモートで接続したり、ネットワーク内の任意のマシンから他のマシンにリモート接続したりできますが、いずれのマシンからローカルホストにもリモート接続できません。 そして、はい、私はそのページを読みました。

ほとんどの攻撃はローカル標高を対象としています。 したがって、すべての構成は「デフォルトで安全」です。 WMI、WinRM、IISループバックなど-すべてのサブシステムは、ローカル昇格を許可する機能を無効にします。
議論にとってはそれほど重要ではありません。 PowerShellリモーティングでデフォルトでsudoを実行できない場合でも、デフォルトでオフに実装するか、対話型セッションのみを許可することができます。

Windowsについて話し始めましたが、Windows以外のシステムの場合は、UNIXソケットアプローチを使用して、PowerShellリモート処理の偽装/昇格を実装できます。

すべてのプラットフォームで同じUXが必要です。 実際には、PSRPはトランスポート（WinRMまたはSSH）を介して機能します。 MSFTは、SSHが好きだと言っていますが、過去2年間で目立った進歩は見られません。 そして、彼らが_近い_将来に3番目のプロトコルを必要とすることは信じられないことです-あまりにも多くの作業（古いシステムとの互換性を維持する必要性）。

ほとんどの攻撃はローカル標高を対象としています。 したがって、すべての構成は「デフォルトで安全」です。 WMI、WinRM、IISループバックなど-すべてのサブシステムは、ローカル昇格を許可する機能を無効にします。
議論にとってはそれほど重要ではありません。 PowerShellリモーティングでデフォルトでsudoを実行できない場合でも、デフォルトでオフに実装するか、対話型セッションのみを許可することができます。

しばらく前にそれを有効にしようとしましたが、他の多くの人から、これは内部のOSによって制限されており、アプリケーションがWindowsの内部に深く接続しないと不可能であると繰り返し言われました。 実際、多くの人が上記のWindows APIの制限を指摘し、PowerShellがそのような機能を提供できない理由の議論としてそれを使用しています。 また、ループバックの昇格が意図的に削除されたCVEを参照した人もいます。 したがって、そのウサギの穴を少し深く掘り下げて謝罪しますが、それが機能するために何を構成する必要がありますか？ それもどこかに文書化されていますか？

すべてのプラットフォームで同じUXが必要です。 実際には、PSRPはトランスポート（WinRMまたはSSH）を介して機能します。 MSFTは、SSHが好きだと言っていますが、過去2年間で目立った進歩は見られません。 そして、彼らが近い将来に3番目のプロトコルを必要とすることは信じられないことです-あまりにも多くの作業（古いシステムとの互換性を維持する必要性）。

どちらもどのプラットフォームでも機能するため、どちらのソリューションも推進する必要があります。

• PSRP：ローカルホストへのSSHは、WindowsとLinuxの昇格で機能します。したがって、psrpサブシステムを使用すると、既に適切なアクセス許可があります。したがって、オブジェクトを渡すには、PowerShellレイヤーのみを統一する必要があります。 正しい？
• UNIXソケットを使用すると、PowerShell Remotingのような同様の機能も提供されますが、執筆時点では、トークンスワッピングを実行するためのローカルシステムとして実行される追加サービスなしでローカル昇格を実行することは難しい制限であると想定しました...

したがって、PowerShell Remotingはすでに存在しているため（また、sshよりも機能しているため）、そのソリューションを優先する必要があると思います。

また、ループバックの昇格が意図的に削除されたCVEを参照した人もいます。

確認できません。 CVEはデフォルトでループバックを無効にすることができると思いますが、まったく無効にすることはできません。
https://github.com/PowerShell/PowerShell/issues/3874#issuecomment-510715727も参照して

@iSazonov ：これは機能しません。低特権アクセストークンのみを提供し、昇格アクセストークンは提供しません（例： Mandatory Label\High Mandatory Level ）。 TrustedHostsが*に設定されていても、低特権のPowerShellから管理者権限を取得できません。 ログオントークンは、Enter-PSSessionの後でも、常にインタラクティブタイプです。
実際にはEnter-PSSession localhost -ScriptBlock {}できますが、資格情報を渡すと「アクセスが拒否されました」。 、いいえ、他のシステムでUACが無効になっている場合は常に「アクセス拒否」がスローされます。

しかし、SSHを使用して試してみましたが、期待どおりに機能し、ログオンタイプがネットワークの昇格されたトークン（ Mandatory Label\High Mandatory Level ）を提供します。

したがって、PSCoreでは、昇格をpsrpに依存できます（ローカルでもEnter-PSSession -HostName localhostを介して、明示的な資格情報が渡されても機能します。
Enter-PSSession -ComputerName localhost -Credential $fooがそうでない場合（$ foo.Usernameが現在のユーザーと同じであっても）

@ agowa338ここではWinRMのセキュリティ機能のバイパスについて説明するべきではないと思います（これはコンプライアンスの重要な領域です）。 （1）プロトコルに関係なく、セキュリティは同じレベルに維持する必要があることを示すことしかできません。つまり、SSHループバックは、Windows内部の動作を考慮して、WinRMの場合と同じように動作する必要があります。（2）PSsudoの実装は機能する必要があります。任意のトランスポート。

@iSazonov ：エクスプロイトを要求しませんでしたが、それを有効にするために構成する必要があるものだけを要求しました。 また、ループバックの昇格を許可するためにWinRMを構成する方法を理解したのはあなただけです。
私はそれを非常に長い間有効にしようとしました。 すべての質問（stackoverflow、reddit、githubの問題など）は、「windows is wird」、「Windowsが何をしているのかわからない」、「どこにも文書化されていない」、「Windowsは提供していません」で終わります。その機能」、「代わりにLinuxを使用する」、「UACを無効にする」、「システム権限で実行されるブローカーサービスを作成する必要があります」。 それで、あなたがそれを理解したならば、あなたの知識を共有してください。

私は（1）プロトコルに関係なく、セキュリティは同じレベルに留まるべきであることを示すことしかできません

それはどういう意味なの？

これは、Windows内部の動作を考慮して、SSHループバックがWinRMの場合と同じように動作する必要があることを意味します

SSHには、まさにそれを行うためにバックグラウンドでブローカーとして機能するシステムサービスがあります。 ネットワークアクセストークンを提供します...

（2）PS sudoの実装は、どのトランスポートでも機能するはずです。

まさにその理由で、WinRMを超えることはありません。 したがって、あなたが言ったことが本当なら、ループバックWinRMを有効にする方法についてのドキュメントが必要です。

あなたがそれを理解したならば、あなたの知識を共有してください。

@ agowa338 MSFTチームから、セキュリティについて公に議論しないように求められ、CoCに従います。 このトピックを深く探求したいというあなたの願望を支持しますが、この議論の一部として、これは、このソリューションをWindowsに統合し、セキュリティコンプライアンスを維持する方法をMSFTにとって頭痛の種です。

まあそれは誰の助けにもなりません。

それを呼び出すには：

• あなたは、WindowsがWinRM内にsudoのような機能を持っていると言います。
• それが存在することも、それを有効/無効にする方法も文書化されていません。
• 使用方法を開示することはセキュリティ上のリスクになります。

申し訳ありませんが、それはバックドアのように聞こえ、機能ではありません。 それ以外の人は使用できません。
また、隠すことによるセキュリティも過去には機能していません...

そのため、現在実装されておらず、ブローカーサービスが必要です...

@ agowa338MSFTチームが結論を

可能でしたが、今年の初めにhttps://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/にパッチKB4480116とその後の累積的な更新でパッチが適用されました。この更新の前は、昇格することができました。 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を使用すると昇格されたトークンがあり、サードパーティのライブラリを使用しても昇格されたトークンを作成するlocalhost PSRemotingを使用でき、パッチがこの機能の完全なブロックではないこともわかります。

MSはUACはセキュリティの境界ではないと繰り返し言っているので、これをセキュリティの問題やセキュリティの境界を越えるとは考えていません。

• https://blogs.technet.microsoft.com/markrussinovich/2007/02/12/psexec-user-account-control-and-security-boundaries/
• https://blogs.msdn.microsoft.com/e7/2009/02/05/update-on-uac/

近いか、同じように動作する可能性がありますが、絶対確実ではありません。 UACをバイパスするこれらの方法の1つは、既知の文書化されたLocalAccountTokenFilterPolicyレジストリプロパティです。 このプロパティの明示的な目的は、フィルタリングされたトークンではなく、ネットワークログオンが常に昇格されるようにすることであり、これを有効にしないと「ループバック」攻撃が防止されることを明示的に示しています。

ローカルのAdministratorsグループのメンバーであるユーザーをより適切に保護するために、ネットワークにUAC制限を実装します。 このメカニズムは、「ループバック」攻撃を防ぐのに役立ちます。 このメカニズムは、ローカルの悪意のあるソフトウェアが管理者権限でリモートで実行されるのを防ぐのにも役立ちます。

最終的には、Windowsには、非対話型の方法で特権を制限から管理者に昇格させる公式の方法がないということです。 Start-Process ... -Verb Runasを使用するのは非常に簡単ですが、UACプロンプトを表示するには対話型ログオンが必要です。 sudoのようなメカニズムがあると、この問題を軽減するのに役立ちますが、適切に行うには、PowerShell固有ではなく、Windows自体での作業が必要になります。 「回避策」はありますが、公式とは呼びません。これは、WinRMを有効にすることの既知の副産物にすぎません。

パワーシェル

PowerShellに影響するWindowsセキュリティの変更|

PowerShellに影響を与えるWindowsセキュリティの変更2019年1月9日最近（2019年1月8日）のWindowsセキュリティパッチCVE-2019-0543は、PowerShellリモートシナリオに重大な変更を導入しました。 これは範囲が狭いシナリオであり、ほとんどのユーザーへの影響は少ないはずです。 重大な変更は、ローカルループバックのリモート処理にのみ影響します。

マークのブログ

PsExec、ユーザーアカウント制御とセキュリティ境界

Windows XPの管理者アカウントから標準ユーザー権限でプロセスを実行する簡単な方法として、約1年半前にPsExecに-lスイッチを導入しました。 制限付きユーザーとしての実行–簡単な方法PsExecがCreateRestrictedToken APIを使用して、次のようなセキュリティコンテキストを作成する方法を説明しました...

エンジニアリングウィンドウズ7

UACの更新

こんにちは、Jon DeVaanが、私たちが受け取った最近のUACフィードバックについてお話しします。 Windows 7を完成させる作業のほとんどは、フィードバックへの対応に重点を置いています。 UACフィードバックは、エンジニアリングの意思決定プロセスのいくつかの側面で興味深いものです。 それらの次元を探求することは興味深いe7につながると思いました...

@iSazonovこれらの提案はいずれも、特にUACが不足している環境では、同じコンソールセッション内から_user-interactive_コマンドの昇格を実現しません。 これらの問題についてマイクロソフトを代表して話すことができるようですが、私が説明したような機能の導入に彼らが単に興味を持っていないかどうかを明確にしますか？

その場合、上記の投稿から解釈したように、このスレッドを閉じるのが賢明なようです。残りのユーザーは、 @ parkovskiのTokenServerのアイデアなどの解決策を他の場所で探す必要があるからです。

これらの問題については、Microsoftに代わって話すことができるようです

私はプロジェクトのコミュニティメンテナーであり、MSFTメンバーではなく、マイクロソフトを代表して話すことはできません。

私が説明したような機能の導入に彼らが単に興味を持っていないかどうかを明確にしていただけますか？

_すべての提案には価値があります。 それらのどれも拒否されません。 議論は、考えられるすべての提案を収集するためだけのものです。_

現在、停滞することなく前進できるように、すべての提案を要約しようとしています。

なるほど。
主なシナリオは、WindowsでのUnixユーザーの採用です。

• 歴史的に、Unixユーザーは1つのコンソールで作業し、sudoはネイティブで_same_コンソールで昇格された権限で作業を行うのに役立ちます
• これまで、Windowsユーザーは、必要に応じて、昇格された権限コンソールで新しいウィンドウを開きます。 これは、マルチウィンドウ環境で便利なため、長年にわたってうまく機能します。 （Windowsユーザーは、Windows CoreとNanoを考慮に入れても、pssudoの恩恵を受けることができます）

したがって、期待は次のとおりです。

• pssudoはインタラクティブセッションでのみ機能します
• pssudoは新しいコンソールを開きません（UACウィンドウはWindowsで受け入れられます、Windowsのセキュリティと精神を壊したくないです）
• pssudoタイムリーなキャッシュ資格情報
• pssudoはセキュリティのためにセッション状態をキャッシュしません
• （可能な限り）同じUXがすべてのプラットフォームにあります
• pssudoはネイティブコマンドを実行します
• pssudoはPowerShellスクリプトブロック/ファイルを実行します

実装の詳細：

• PowerShellリモーティングは、最も強力で機能的なソリューションです。 すでに実装され、機能しています。 他のユーザーもこの機能をエミュレートして、ユーザーごと/セッションごと/実行スペースごと/スコープの状態ごとにPowerShellスクリプトブロックを実行する必要があります。
• すべてのWindowsインフラストラクチャがWinRMに基づいているため、優先されるトランスポートはWinRMです。 WinRMにはある程度の投資が必要ですが、MSFTはSOAPに基づいているため、これを望んでいません。
• SSHトランスポートは可能性があります。 これはまだWindowsの標準ではありません。 実装と保守には多額の投資が必要です。 また、古いシステムのサポートには問題があります。
• Unixソケットのような他のトランスポート。 インフラストラクチャだけでなく、PowerShellにも多額の投資が必要です。

@ mklement0私はここであなたが通常素晴らしいことをしているのだろうか:-)あなたは私を敵から奪う:-)

渡されたコマンドを使用してPowerShellインスタンスを起動する特権を必要とするWindowsバイナリを作成してみませんか。 正しく動作するには、コンソールモードのアプリである必要があります。 次に、Linuxの場合、提供されたコマンドでPowerShellインスタンスを起動するアクセス許可を必要とするスクリプトを記述します。 これが理論と同じように実際に機能する場合、PowerShellは昇格されたアクセス許可で起動され、コマンドを実行して終了します。

渡されたコマンドを使用してPowerShellインスタンスを起動する特権を必要とするWindowsバイナリを作成してみませんか。 正しく動作するには、コンソールモードのアプリである必要があります。

Windows APIがそれを防ぎ、コンソールアプリが新しいウィンドウで開く原因になります。 考えられる回避策についてはすでに説明しました。

覚えておくべきことの1つは、これがどのように実装されても、昇格されたプロセスとの間のプロセスホップが常に存在するということです。 これは、パイプラインに常に逆シリアル化されたオブジェクトがあり、それらの制限が適用されることを意味します。 多くの場合、これは問題にはなりませんが、コマンドレットがライブの.NETオブジェクトを予期している場合は、機能しません。

SSHでJEAをサポートするには、とにかくそのサービスとしてのWinRMの必要性を置き換える一般化されたデーモン/サービスが最終的に必要になります。 その際、パイプラインの一部を昇格させるためにそれを使用して評価します。

参考： https ：

GitHub

gerardog / gsudo

Sudo forWindows-新しいコンソールホストウィンドウにまたがらずに昇格して実行-gerardog / gsudo

参考： https ：

GitHub gerardog / gsudo Sudo forWindows-新しいコンソールホストウィンドウにまたがらずに昇格して実行-gerardog / gsudo

さらに良い
http://blog.lukesampson.com/sudo-for-windows

GitHub

gerardog / gsudo

Sudo forWindows-新しいコンソールホストウィンドウにまたがらずに昇格して実行-gerardog / gsudo

Luke Sampson-Sudo for Windows

Sudo for Windows

さらに良い

番号。

Gsudoは毎回パスワードの入力を求めず、インストールと使用が著しく高速になります。

このチケットだけでなく、関心から判断して、この問題は受け入れられるべきである（つまり、もう少し時間と組織が与えられるべきである）ように思われます。 現在認識されている技術的な問題は積極的な関与なしには解決されないため、それを作業タスクとして公式に認識しないことは正しくありません。

私はgsudoを数か月使用していますが、従来のWindowsUACにいつも戻ることは想像できません。

@majkinetorこの問題はhttps://github.com/PowerShell/PowerShell/issues/11343でスピンオフされ、設計に関する詳細な議論が行われました。