Powershell: sudo 지원<powershell cmdlet=""/>

흠! 매우 흥미로운. 그러나 실제 행동은 예상대로라고 생각합니다. Windows에서와 같이 sudo와 같은 명령이 없습니다.
그러나 'sudo powershell'을 사용하고 'sudo powershell'을 사용하여 만든 foo.txt 제거를 수행하면 Remove-Item을 사용할 때 작동합니다. 물론 비 승격 권한에서는 작동하지 않습니다.

PowerShell 내에서 Linux 명령 ( "sudo nautilus")에서만 'sudo'를 사용합니다.

:)

Windows에서도 cmdlet을 다른 사용자 또는 승격 된 권한으로 실행할 수있는 유사한 기능과 이식 가능한 스크립트에 의존 할 수있는 기능이 있으면 좋습니다. 이를 위해 RFC가 필요할 수 있습니다.

이 기능은 # 3506을 해결하는 데 유용합니다.

이것이 해결되지 않으면 Linux를 적응시키는 데 방해가 될 것입니다. 우리는 bash를 sudo 할 수 없으며 마찬가지로 sudo powershell을 수행 할 수 없습니다.

Maximo에 동의합니다. sudo를 bash에 맡기고 예상 기능에 대한 스캐 폴딩으로 sudo를 사용하여 powershell에서 상승을 수행하기위한 새 cmdlet을 만들어야합니다.

@dantraMSFT가이 를 조사하고 있습니다. Dan이 이에 대한 현재 생각에 대한 업데이트를 제공 할 수 있습니까?

@pixelrebirth 당신이 기대하는 것에 대해 더 자세히 설명 할 수 있습니까? 대기, 출력 리디렉션 또는 파이프 라인 리디렉션으로 간단한 실행을 기대하고 있습니까?
몇 가지 예제 사용도 유용합니다.

@dantraMSFT 인수를 위해 cmdlet과 같은 새 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 그녀가 괜찮

기본 요약은 @dantraMSFT 가 sudo powershell -c "invoke-foo" 할 수 있지만 분명히 작동하지 않습니다.

@dantraMSFT : 조사를 진행하면서 모든 사람이 서로 다른 접근 방식의 장단점을 이해할 수 있도록 상태를 게시 할 수 있습니까?

당연해 보일지 모르지만 sudo 소스 코드를 살펴보고 어떻게 관리하는지 살펴보면 저수준 코딩이 필요할 수 있습니다. 도움이 될 더 깊은 코드 이해가 있었으면합니다.

그녀는 괜찮습니다. 그녀는 수술 용 엉덩이를 느낍니다. 이에 대한 빠른 응답에 감사드립니다. 나는 그것을 풀면 여기에 게시 할 약간의 해킹 작업을하고 있습니다.

@pixelrebirth 참고로 sudo는 setuid 비트를 사용합니다. 자세한 내용은 https://unix.stackexchange.com/a/80350/86669 를 참조

기본 Windows sudo가 있어야합니다 (따라서 Powershell을 통해서만 사용할 수있는 옵션이 허용되지만 문제는 여기에 속하지 않을 수 있습니다). 저는 처음부터 Powershell을 사용해 왔으며 위의 Invoke-Elevated (또는 매일 사용하는 제 자신의 것)과 같은 99 개의 sudo 스크립트 변형을 보았습니다. Powershell에 이와 같은 cmdlet을 포함하는 것은 한 걸음 더 나아갈 수 있지만 Linux에서 작동하는 방식에 비해 모두 번거 롭습니다.

저에게 성가신 것 중 하나는 Windows에서 기술적으로 가능한지 확실하지 않은 Powershell / Windows에서 구현되고 싶은 새 셸 창 (리눅스가 아님)을 시작한다는 것입니다.

Windows에서 사용할 수있는 다른 cmdlet ( "Invoke-Elevated")에 대한 아이디어가 마음에 들지만 high로 실행할 스크립트를 만들어야하는 경우 'sudo'로 PowerShell을 열지 않는 이유를 이해할 수 없습니다. 특권?

특히 어쨌든 어떤 종류의 높은 권한 자격 증명으로 실행되도록 예약 될 작업을 자동화하는 경우 특히 그렇습니다.
:)

이는 일반적인 워크 플로우가 아니기 때문입니다. 당신은 'sudo'가 아니라 그곳에서 영원히 살며, 특정 명령을 sudo하고 non-sudo 세계에 살고 있습니다. Windows에서는 빠른 방법이 없으며 Powershell 자체는 시작 속도가 매우 느립니다. 특히 프로필 요소가 거의 포함되어 있지 않습니다.

일반적인 매일 세션에서 특정 명령을 20 번 sudo하고 다른 명령은 권한없이 실행합니다. 이것이 sudo의 요점입니다. 필요할 때만 특권을 높이고 자주 필요할 수도 있습니다.

내 워크 플로는 명령 실행, 권한에 대해 불평합니다. 권한으로 마지막 명령을 다시 실행하는 sudo -L 입니다. posh는 시작 속도가 너무 느리기 때문에 관리자 셸을 실행하고 계속해서 살아갑니다. 분명히 좋은 생각은 아닙니다.

감사합니다 @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 모듈에는 세 가지 기능이 있습니다.

• New-SudoSession
• SudoSession 제거
• Start-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

상승 된 명령을 삽입 할 수있는 ElevatedPSSession을 열기위한 경우 New-SudoSession. 아이디어는 상승이 필요한 여러 작업이 포함 된 더 긴 스크립트에서 처음에 ElevatedPSSession을 만들고 UAC 프롬프트를 한 번받은 다음 필요할 때 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

내부적으로 Non-Elevated PowerShell 세션에서 수행하는 작업은 다음과 같습니다 (세션이 이미 상승 된 경우 아무 작업도 수행하지 않음).

• WinRM / WSMan이 활성화되고 CredSSP 인증을 허용하도록 구성되었는지 확인합니다 (그렇지 않은 경우
  구성 변경)

• 로컬 그룹 정책 개체 확인 ...

  컴퓨터 구성-> 관리 템플릿-> 시스템-> 자격 증명 위임-> 새 자격 증명 위임 허용

  ... WSMAN / LocalHostFQDN을 통한 연결을 허용하도록 활성화 및 구성되었는지 확인합니다.

• New-PSSession cmdlet을 사용하여 Elevated PSSession을 만듭니다.

• Elevated PSSession의 -Expression 매개 변수에 전달 된 식을 실행합니다.

• Elevated 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) 아마 의심 하셨겠지만, 저는 어떤 라이선스를 고를 지 잘 모르겠습니다. Apache 2.0을 사용하도록 전체 기타 powershell 리포지토리를 업데이트하고 Apache 2.0을 참조하도록 Sudo.psd1을 업데이트했습니다 (내 git repo 및 PowerShell Gallery에서). 이것이 사람들에게 유용 할 수 있기를 바랍니다! 모든 조언 / 비판을 환영합니다!

@ SteveL-MSFT 라이센스가 Apache 2.0 인 경우 사용할 수 있습니까? MIT가되기 위해 필요한 경우 알려 주시면 업데이트하겠습니다.

@pldmgg 솔루션의 가장 큰 문제는 CredSSP를 사용하는 것입니다. 이는 자격 증명 처리를위한 덜 안전한 방법이며 UAC 경계에 많은 위험을 노출한다고 생각합니다.

Powershell Magaize 에서 인용하려면,

"CredSSP를 사용하여 도메인 관리자 계정을 사용하여 사용자의 워크 스테이션에 인증하는 것은 좋지 않습니다. 기본적으로 왕국에 키를 제공하는 것입니다."

"신뢰성이 낮은 컴퓨터에 높은 신뢰 자격 증명을 입력하지 마십시오."

UAC의 요점은 컴퓨터의 응용 프로그램을 신뢰하지 않는 것입니다. 내 컴퓨터에서 혼란을 일으키는 sudo 명령에 동의하더라도 일반적으로 내 자격 증명이 없습니다. sudo 명령이 이제 내 도메인 자격 증명에 대한 명확한 액세스 권한을 가지고 있다면 내 네트워크를 손상시키는 데 훨씬 더 많은 피해를 줄 수 있습니다.

솔루션이 CredSSP없이 작동하도록 만들 수 있습니까? 그렇지 않다면 CredSSP를 사용하여 해결하려고했던 문제는 무엇입니까? 이 정보는 PowerShell 팀이보다 안전한 솔루션을 찾는 데 유용 할 수 있습니다.

@pldmgg Apache 2.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 Restricted Admin 모드 또는 새로운 "Credential Guard"가 있습니다.)

추신 :이 기사는 PowerShell 보안에 대한 참조 자료가되었습니다 (그리고 Credential Guard에 대해 배웠던 곳입니다). 적극 추천합니다.

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

6.0.0의 경우 다음과 같이 끝날 것이라고 생각합니다.

Linux에만 존재하는 sudo라는 스크립트 함수 (Windows 상승 지원을 연기합니다). 인수가 cmdlet / scriptblock이면 해당 인수로 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 유형 cmdlet에 투자하는 것이 좋습니다.

일반적으로 고도를 변경하려면 UNIX에서 setuid 비트를 사용하는 것이 필요하며 그 자체가 sudo입니다. sudo는 쉽게 에뮬레이션 할 수없고 보안을 위해 에뮬레이션해서는 안되는 특수 바이너리입니다. 문제의 명령을 실행하는 powershell의 임시 인스턴스를 시작하는 데 실제 sudo를 사용하십시오. 또한 전체 셸을 sudo하는 것은 원격 서버에서 열린 셸을 잊을 수 있다는 점을 고려할 때 다소 안전하지 않습니다. sudo는 장기적으로 시스템을 보호하는 몇 분 후에 사용자가 상승했다는 것을 잊는 메커니즘을 가지고 있습니다. 이 문제를 해결하면 더 많은 사람들이 Linux 서버의 프로덕션에서 powershell을 사용할 수 있습니다. 상황에 따라 powershell은 보안이 생산에서 가장 중요하기 때문에 부업으로 남을 것입니다.

@borgdylan 오늘은 PowerShell Core 내에서 sudo pwsh -c foo (또는 sudo nativecmd )를 수행 할 수 있습니다. 기존 PowerShell Core 세션 내에서 cmdlet을 sudo 할 수있는 것이 욕망이라고 생각합니다. 우리는 여기서 sudo 를 다시 만들려고하는 것이 아니라 사용하기 쉽도록 약간의 구문 적 설탕을 가지고 있습니다.

# 1527과이 문제가 이정표로 밀려나 가면서 저는 궁금해하기 시작했습니다. 모든 사람이 관리 작업을 수행하기 위해 루트 세션에 로그인하는 것이 정말 편한가요? PS가 어떤 식 으로든 관련되어있을 때 PowerShell 명령을 호출하는 편리한 방법은 거의 없습니다.

@MathiasMagnus 나는 이것을 철저히 테스트하지는 않았지만 sudo에서 암호를 요구하지 않도록 공통 또는 반복적으로 사용되는 명령을 구성 할 수 있습니다. 테스트하기 위해 visudo로 이것을 추가했습니다.

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

그런 다음 PowerShell SSH 원격 세션을 통해 sudo pwsh -c 'cat /etc/sudoers' 를 호출 할 수있었습니다. 보안을 수행하는 방법과 sudoers에서 정확히 무엇을 구성했는지에 따라 (예 : All=(ALL:ALL) 는 약간 열려 있습니다 ...) 이것은 안전하거나 위험 할 수 있습니다.

Linux로 ssh하는 경우 (즉, PowerShell SSH 원격 대신 bash 쉘로) 내가 말할 수있는 한 pwsh 내에서 일반 암호 프롬프트로 sudo를 실행할 수 있습니다.

불가능한 것이 아니라 현재의 해결 방법에 약간의 수하물이 함께 제공됩니다.

@MathiasMagnus # 1527은 좋은 해결 방법이 없기 때문에 여전히 6.1.0을 대상으로합니다. cmdlet의 경우 주된 문제는 sudo'd cmdlet과의 파이프 라이닝의 복잡성입니다. 단일 작업의 경우 sudo pwsh -c 가 실행 가능합니다. 물론 커뮤니티의 누군가가 PR을 제출하면 기꺼이 받아 들일 것입니다.

Windows에서 이것은 이제 ssh 연결을 높이 지 않으면 해결할 수 없다고 생각

작동하지 않고 조치를 취하지 않는 일에 대해 쉽게 알아 차릴 수 있지만 내 전문 지식은 다른 곳에 있습니다. 저는 주로 C ++ 및 GPGPU 라이브러리와 Vcpkg에 많은 CMake 포팅을 수행하는 데 기여합니다. 저는 C #을 작성한 적이없고 그럴 능력이 없을 것 같습니다. 그러나 나는 ~ 12 대의 작은 클러스터를 관리한다. 손으로 관리 할 수있는 경계에 있지만 sudo 기능이 심각하게 누락되었습니다. 즉, 우분투에서 루트 사용자를위한 로그인을 만들지 않으려는 경우 눈살을 찌푸리는 일입니다. DSC Core가 해결책이 될 것이지만, 1 년 전에 발표되었지만 최근 무기한 연기되었습니다.

현재 Linux의 PowerShell Core는 자동화 된 작업 방식과 Linux 시스템 관리자에게 친숙한 임시 스타일 사이에 갇혀 있습니다. 누군가가이 문제에 참석할 시간을 갖기를 바랍니다.

@MathiasMagnus 이것은 모든 사람이 원하는 것이지만 해결하기위한 간단한 문제는 아닙니다. 네이티브 명령에 대해 sudo 를 사용하면 제대로 작동하지만 실제로 cmdlet에 대해 sudo 를 실행할 수는 없습니다. 해결 방법은 pwsh 내에서 pwsh를 호출하는 것입니다.

sudo pwsh -c 항목 제거

주요 문제는 파이프 라인 내에있는 경우입니다.

get-item foo * | sudo 항목 제거

@ SteveL-MSFT 적어도 개념은 그렇게 복잡하지 않습니다. 당신의 생각을 말 해주세요.

모든 경우를 처리하려면 sudo, su 및 로그인 바이너리의 조합이 필요합니다.

다음을 수행해야합니다.

• 콜백에 대한 유닉스 소켓을 만들고 대상 사용자 만 액세스 할 수 있도록 허용합니다.
• 호출자에게 sudo 액세스가 허용되었는지 확인합니다 ( su , sudo 및 login 의 소스 코드를 간단히 복사 할 수 있다고 생각합니다)
  
  
  
  • / etc / sudoers가 존재하는 경우 구문 분석해야합니다.
    
    
    
    
    
    • 특정 명령 만
    
    
    
    • 대상 사용자 암호를 사용하여
    
    
    
    • 자격 증명을 확인하지 않고 (암호 없음)
    
    
    
  
  
  • 그렇지 않은 경우 pem을 호출하여 사용자가 root 사용자의 자격 증명을 직접 "알고 있는지"확인해야합니다.
  
  
  • 대상 사용자 자격 증명도 모르는 경우 액세스를 거부하고 powershell에서 예외를 throw합니다.
  
  
• 유효성 검사가 통과되면 사용자 컨텍스트를 루트 또는 대상 사용자로 전환해야합니다.
• 사용자 컨텍스트를 전환하면 새 프로세스는 유닉스 소켓에 연결하여 실행중인 원래 powershell로 다시 통신을 설정해야합니다.
• 사용자가 "exit"를 입력하면 유닉스 소켓을 통해 완료되었다는 신호를 보내고 종료하면 사용자는 자동으로 호출자 권한으로 돌아갑니다. 따라서 호스트 파워 쉘 만 있으면 프롬프트를 표시하거나 다음을 실행할 수 있습니다. 교수.
• 대신 호스트 powershell이 ​​종료되면 unix 소켓이 닫히고 상승 된 powershell이 ​​터미널을 닫는 것처럼 실행을 중지하고 종료해야합니다.

실행 흐름은 다음과 같습니다.
PWSH (소켓 /proc/self/change-user.socket 생성) => PWSH-SU (소켓 및 대상 사용자를 매개 변수로 호출, PWSH-SU는 루트 자체로 실행되도록 suid 설정) => 대상 사용자가 연결할 때 PWSH 유닉스 소켓에.

가장 시간이 많이 걸리는 부분은 powershell이 ​​유닉스 소켓을 통해 내부적으로 연결되도록하는 것입니다. 다른 유닉스 응용 프로그램이 수행하는 입력 및 출력 링크를 리디렉션하는 것만으로는 충분하지 않습니다. 파이프를 호출 할 때 문자열뿐 아니라 객체를 처리하기 때문입니다.

세 바이너리를 모두 사용하는 이유는 무엇입니까?
여러 사용자가 감사 기능 을 잃지 않고 루트 컨텍스트로 전환 할 수 있도록하려면 sudo 가 필요합니다.
su 는 대상 사용자 자격 증명을 사용하여 다른 사용자로 전환하는 데 사용됩니다.
login 은 완전히 새로운 로그인 세션을 만드는 데 사용됩니다.
이러한 모든 기능을 powershell에도 포함하면 하나만있는 것보다 많은 경우에 유용 할 수 있습니다.

파이프를 사용하면 덜 놀랍고 편리한 방식으로 Windows에서도이 작업을 수행 할 수 있습니다. 모든 "sudo"스크립트 + UAC 클릭으로 다른 셸을 얻는 것이 싫지만 이와 같은 파이프를 사용하면 동일한 셸 내에서 수행 할 수 있습니다. Linux에서와 같이 이미 관리자로 실행중인 다른 인터프리터와 파이프를 통해 통신하고 실제 sudo 항목을 구현할 수 있습니다 (예 : 프롬프트 시간 초과 또는 사용자 지정 powershell 끝점 대신 명령이있는 sudoers 파일).

이것에 대한 생각을 보니 정말 기쁘지만 실제 구현에 관해서는 우리가 조금 앞서 가고있는 것 같습니다. 첫 번째는 시스템이 상승되지 않은 프로세스에서 상승 된 프로세스, 스레드를 생성하는 방법이 필요하다는 것입니다. UAC를 거치지 않고 시작할 PowerShell의 상승 된 인스턴스를 만들 수없는 경우 cmdlet 문제는 ​​실제로 해결할 수 없습니다. IMO, 여기서 다루어야 할 첫 번째 시나리오는-제한된 SSH 세션이 있습니다-관리자 권한으로 일반 exe를 어떻게 실행합니까?

여기에서 실험을 시작했지만 (현재는 리팩토링 중이지만 개념은 작동하지만) 타사 앱이 실제 솔루션이라고 생각하지 않습니다. Windows가 먼저 'sudo'exe를 제공하는 것을보고 싶습니다. 이것은 runas 를 사용하여 자격 증명 프롬프트가있는 승격 된 프로세스를 만드는 것처럼 간단 할 수 있지만 첫 번째 단계 없이는 모두 이론적입니다.

UAC를 거치지 않고 시작할 PowerShell의 상승 된 인스턴스를 만들 수 없으면 cmdlet 문제를 실제로 해결할 수 없습니다.

이를위한 한 가지 가능성은 '최고 권한으로 실행'옵션과 함께 예약 된 작업을 사용하는 것입니다.

예,하지만 만들려면 이미 관리자 권한이 있어야합니다. 그것이 psexec이하는 일입니다. 내가 아는 한, 지금 당장은 UAC를 거쳐야합니다. 저는 그 변화를보고 싶습니다. 모든 SSH 세션이 상승함에 따라 그것은 일종의 보안 문제입니다. 개인 키가 설정된 다른 컴퓨터 (또는 루프백 시나리오)에서와 같이 일부 스케치 소프트웨어가 내 Windows 컴퓨터에 SSH를 시도하면 원하는 모든 작업을 수행 할 수 있습니다.

@parkovski 내 솔루션은 Linux / MacOS 및 기타 모든 * NIX OS 전용이었습니다. Windows는 SUID 및 GUID를 지원하지 않습니다.
sudo는 현재 Windows에도 존재하지 않기 때문에이 문제의 범위를 벗어납니다.

UAC 문제를 해결하기 위해 Windows는 향후 SUID 및 GUID를 구현해야합니다. 다른 모든 것은 오랜 문제에 대한 더러운 해결 방법입니다.

예,하지만 만들려면 이미 관리자 권한이 있어야합니다.

맞지만 UAC 팝업을 트리거하지 않습니다.

UAC는 Microsoft의 응용 프로그램 호환성 도구 키트를 사용하여 공식적인 방식으로 건너 뛸 수도 있습니다.

Windows는 SUID 및 GUID를 지원하지 않습니다.

Windows는이를 지원할 필요가 없으며 해당 OS에서 개념이 유효하지 않습니다.
권한 모델은 ACL을 기반으로하며 단일 그룹 소유권이 없습니다.

또한 Windows에서 전체 sudo 복제본 일 필요는 없으며 관리자 명령을 호출하는 더 친숙한 방법입니다.

Windows 사용자는 아마도 오늘 상승 된 PowerShell 세션을 여는 데 익숙한 반면 Linux 사용자는 필요에 따라 루트가 아닌 sudo로 실행되기를 기대하므로 Windows 지원을 연기하는 것이 좋습니다. 우리는 디자인이 향후 Windows 지원을 배제하지 않는지 확인하고자합니다. 나는 또한 임의의 사용자가 그것을 단순화하기보다는 루트에 대해 단순히 sudo를 활성화하는 데 초점을 맞추고 이것이 사용량의 90 % 이상이라고 생각합니다.

@ SteveL-MSFT

또한 임의의 사용자가 아닌 루트에 대해 단순히 sudo를 활성화하는 데 초점을 맞출 것입니다.

사용자 컨텍스트를 루트로 전환하는 것은 다른 사용자로 전환하는 것과 거의 동일하기 때문에 이것이 큰 차이를 만들지는 않을 것이라고 생각하지만 위에서 설명한 추상에 대한 완전한 su / sudo 경험을 제공합니다.

Windows 사용자는 오늘 상승 된 PowerShell 세션을 여는 데 익숙 할 것이므로 Windows 지원을 연기하는 것이 좋습니다.

내가 함께 일했던 대부분의 사람들은 가능한 경우 UAC를 비활성화했습니다.

불행히도 이것은 많은 환경에서 실제로 옵션이 아니며 MS가 UAC를 완전히 버리고 버릴 것 같지 않습니다. 😕

이 문제는 UAC에 관한 것이 아닙니다. 그러나 내 관점에서는 완전히 버려야하며 엄격한 두 계정으로 교체해야합니다. * 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 Core 세션 내에서 cmdlet을 sudo 할 수 있습니다 "의 경우에는 해당되지 않습니다.

그러나 호출 명령의 전체 세션에 상승 된 컨텍스트를 제공하는 것이 얼마나 중요한지 궁금합니다. 다른 셸에서 sudo 여전히 새 컨텍스트에서 제공된 명령을 실행합니다.

Windows에서 관리자로 명령을 실행하는 데 잘 작동하는 기본 sudo를 구현했습니다. "RunAs"가 해당 플랫폼에서 올바르게 상승하는지 여부를 모르기 때문에 이것이 linux / mac에서도 작동하는지 확실하지 않습니다.

프로필 수정:

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 이것은 GUI를 사용할 수있을 때 유용한 해결 방법이며 그동안 유용하지만 GUI 액세스 없이는 작동하지 않기 때문에 여전히 실제 sudo가 아닙니다. 원격 셸 (ssh)에서 말 그대로이 작업을 수행하는 유일한 방법 은 여기에서 보여 주려고 시도한 서비스와 클라이언트입니다.

몇 가지 일반적인 제안을 해결하기 위해 모든 가능성을 살펴 보았습니다.

• UAC를 비활성화하는 것은 해결책이 아닙니다. 개인적 선택으로 만들 수있는 해결 방법이지만이 문제에 대한 일반적인 해결책은 아닙니다.
• UAC (내가 본 모든 "sudo"스크립트)를 팝업하는 것은 한 번만 수행하여 상승 된 원격 세션을 시작하는 것을 포함하여 해결책이 아닙니다.
• GUI를 필요로하는 것은 _ 전혀 _ 해결책이 아닙니다. 여기서 ssh를 사용하고 GUI를 사용할 수 없다고 가정 해 봅시다.
• Windows에 대한 주요 변경이 필요한 것은 해결책이 아닙니다. 우리는 UAC가 더 나은 것으로 바뀌는 것을 믿을 수 없습니다.
• Microsoft의 서명 된 바이너리조차도 UAC가 high로 설정되면 작동하지 않기 때문에 해결책이 아닙니다 (wsudo readme에서이 문제가 잘못되었습니다. 나중에 수정하겠습니다).
• Windows에서 sudo에 대한 유일한 실제 솔루션은 성공적인 인증시 사용자 프로세스를 향상시키는 서비스입니다. 다른 아이디어를 듣고 싶지만 먼저 조사해주세요.

기본적으로 누군가는 많은 일을해야합니다. 우리가 원하는 것은 일단 PowerShell이 ​​Unix에서 이것을 지원하면 Windows에서 대체품이며 sudo가 작동 할 것으로 예상 한대로 작동하는 것입니다 (GUI 없음, UAC 없음).

먼저이 문제의 범위를 명확히 할 수 있습니까? 지금 여러 사람이 서로 다른 주제에 대해 이야기하고있는 것 같습니다.
이 문제입니까?
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와 동일하지만 (창에는 유닉스 소켓도 있음) 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의 요점 중 하나는이를 사용하는 시스템 간의 호환성 문제가 적다는 것입니다. 이와 관련하여 시스템 X에서만 무언가를 수행하는 것은 IMO가 허용되지 않습니다.

나는 CLI 사용자로서 sudo 가 suders 파일 또는 일부 창을 사용하여 완전히 날아간 Linux sudo라면 덜 신경 쓸 수 없습니다. Sudo는 OS의 고도 기능에 대한 인터페이스입니다. 이러한 인터페이스는 '백엔드'에 관계없이 거의 동일하게 작동하도록 만들 수 있습니다.

그렇지 않으면 @parkovski 가 GUI 스탠드에 대해 지적합니다. 이유 중 Windows Core를 추가 할 것입니다.

CLI 세계에 대한 유일한 또 다른 프론트 엔드라는 점을 감안할 때 터미널 앱이 sudo를 논의하기에 더 좋은 장소 인 이유는 무엇입니까? 동일한 논리로 ConEmu 저장소에 티켓을 제출할 수 있습니다.

그 저장소는 단지 "터미널 앱"이 아니기 때문입니다. 이를 실행하는 팀은 기본적으로 Windows의 텍스트 모드 부분을 소유하고 있으며 시간이있을 때 sudo를 구현하는 데 관심이 있다고 이미 말했습니다. 반면에 PowerShell 팀이나 ConEmu의 누구도 제안하지 않았습니다.

Windows sudo가 여기서 범위를 벗어났다고 생각하는 이유는 제대로 수행하는 것이 상당히 많은 작업이며 PowerShell 자체와 직교한다는 것을 이미 확인했기 때문입니다. PowerShell은 존재하는 경우이를 사용할 수 있지만 실제로는 특정 셸에서 독립적 인 구성 요소입니다.

반면에 PowerShell은 플랫폼이나 바이너리가 실제로 작동하는 방식에 관계없이 sudo 바이너리를 통해 cmdlet을 실행할 수 있다는 것은 완전히 여기에 속하는 PowerShell의 일부 여야합니다.

나는 CLI 사용자로서 sudo가 suders 파일 또는 일부 창을 사용하여 Linux sudo를 완전히 망가 뜨리면 신경 쓸 수 없습니다. Sudo는 OS의 고도 기능에 대한 인터페이스입니다. 이러한 인터페이스는 '백엔드'에 관계없이 거의 동일하게 작동하도록 만들 수 있습니다.

네, 절대적으로 그래야합니다. sudo는 아직 Windows에 존재하지 않고 많은 작업이 필요하며 아마도 PowerShell 팀에서 작성하지 않을 것입니다. 그러한 것이 존재한다면 PowerShell이 ​​Windows에서도 작동하는 방식으로이를 구현하기를 바랍니다.

어쨌든,이 문제는 온갖 방향으로 진행되고 있기 때문에 공식적인 답변을 얻을 때까지 추가 의견을 연기하겠습니다.

이것에 대한 의견이 있습니까?
http://blog.lukesampson.com/sudo-for-windows
scoop install sudo 와 함께 설치되어 내가 생각할 수있는 가장 가까운 것입니다. 유닉스 sudo처럼 작동합니다-상승으로 명령을 실행합니다. 모든 사용자를 위해 pip 또는 Install-Module과 함께 사용합니다.

Luke Sampson-Windows를위한 Sudo

Windows 용 Sudo

@ Restia666Ashdoll Invoke-ElevatedCommand 로 이름이 바뀌면 괜찮습니다.
sudo는 명령을 상승시킬뿐만 아니라 사용자를 가장하고 ( sudo -u nobody command ) 권한을 "삭제"하는 역할을하기 때문입니다. 또한 이미 존재하는 이름을 재사용하는 것은 특히 기능과 매개 변수가 다른 경우에는 이미 나쁜 생각으로 판명되었습니다.
나는 이미 위장을 사용하는 진정한 sudo의 모양과 작동 방식에 대해 설명했습니다.

@ Restia666Ashdoll 이 스레드 에서이 의견 을 읽으십시오.

@parkovski 그것은 단지 몇 가지 명령으로 만 작동하는 -Verb RunAs의 래퍼입니다. 내가 연결 한 것은 거의 모든 것에 사용할 수 있습니다. 예를 들어 다음과 같이 사용합니다- sudo pip install httpie .

내 게시물을 읽지 않았나요?

"NOT A SUDO ON WINDOWS DISCUSSION"과 같은 내용을 포함하도록 제목을 편집 할 수있는 방법이 없다고 생각합니다. 나는 개인적으로이 질문에 계속 대답 할 의무가 없다는 것을 알고 있지만 사람들은 조사를하지 않고 똑같은 말을 계속합니다.

이 사람의 구독 취소 링크를 클릭하려고했는데 안타깝게도 그 사람으로 로그인하지 않고는 그렇게 할 수 없습니다.

이미 @troymoore 를 GitHub에 신고

여기에서 언급하지 않은 독특하고 다른 솔루션을 제안하고 싶습니다. 명명 된 파이프와 같은 것을 사용하여 명령을 상승 된 프로세스로 직렬화 한 다음 직렬화 된 출력을 호출 프로세스로 반환하는 것은 어떻습니까?

다음은 이것이 NT에서 어떻게 작동하는지 보여주는 기능 모듈입니다 : https://github.com/mmillar-bolis/Invoke-AsAdmin

물론 완벽하지는 않지만 다른 콘솔을 열지 않고도 간단한 작업과 파이프 라인을 향상시킵니다. 나는 sudo의 디자인을 복제하는 것이 가장 장기적인 해결책이 될 것이라고 믿지 않기 때문에 이것을 sudo와 비슷하다고 생각하지는 않지만이 모호한 상승 문제에 대한 다른 접근 방식이 더 건설적인 논의가 될 것이라고 생각했습니다.

편집 : 나는 또한 언급해야한다,이 UACless 상승에 대한 @parkovski의 요청을 수행하지 않습니다.

JEA처럼 보입니다.
직렬화의 경우 모든 모듈이이를 지원하는 것은 아닙니다.

JEA처럼 보입니다.

네, 그게 아이디어입니다.

직렬화의 경우 모든 모듈이이를 지원하는 것은 아닙니다.

코드에서 보셨 겠지만 파이프의 다른 쪽 끝에서 코드를 재구성하는 텍스트 스트림을 사용하면이 문제가 완화됩니다. 나는 이것이 느리다는 것을 인정하지만 그럼에도 불구하고 새로운 해결 방법입니다. JEA에 대한 귀하의 언급은 여기서도 큰 영향을 미쳤습니다. 코드의 일부가 상승 될 필요가 없다면 그렇게해서는 안됩니다.

이 모듈은 NT의 GUI 세션 내에서 대화식 명령을 향상시키는 매우 구체적인 문제를 해결하기위한 것입니다. 이 일은 누군가가 네이티브 ssh가 NT를위한 것이 될 것이라고 상상하기 전에 5 년 전에 시작되었습니다. 나는 이것이 NT가 상승을 처리하는 방법과 관련된 문제 라는 점에 동의한다. 따라서 서비스가 윤곽이있는 형태의 명령 상승을 수신하고 제공하지 않으면 sudo, pkexec 또는 doas와 유사한 사용 사례를 쉽게 달성하기가 다소 어렵다.

그러나 PowerShell이 ​​모든 형태의 명령 상승을 지원하려면 먼저 sudo와 같은 구현이 NT에 존재해야한다는 열반의 오류에 의해 중단되는 대신 쉘 세션 내에서 어떤 형태의 JEA 대화 형 상승을 먼저 추진하지 않겠습니까?

이것은 적어도 NT 세계에서 향상된 보안 관행을 촉진 할 것입니다. 대화 형으로 실행하는 cmdlet과 별도의 콘솔 세션을 시작하는 cmdlet을 모두 구현하지 않는 이유는 무엇입니까? 또는 더 나은 방법은 사용 사례가 다른보다 스파르타적인 cmdlet 집합과 함께 상승 된 세션을 시작하는 현재 방법을 홍보하는 것입니다. 적어도 한 걸음 앞으로 나아갑니다.

또한 Python elevate 라이브러리조차도이 모듈이하는 일을 할 수 없다고 덧붙일 수 있습니다. 이미 작동하지 않는 다른 모듈을 찾았습니까? 내 요점은 아마도 내 것보다 더 똑똑한 사람이이 모듈을 받아 들일 수 있고 NT에 적합한 방향으로 아이디어와 함께 실행할 수 있다는 것입니다. 그 후, NT와 * nix가 중간에 만나는 플랫폼의 시작이있을 수 있으며,이를 통해 PowerShell에 대한보다 일반적인 구현을 수정하여 명령을 향상시킬 수 있습니다.

그것은 적어도 내 2 센트입니다. 그러나 코드를보고 그 안에있는 아이디어가 좋지 않다고 느끼면 이해할 것입니다. 나는 아직 이런 것을 시도하는 사람을 보지 못했습니다.

(a) 예 이것은 매우 어려운 문제이고, (b) MS에서만 제대로 해결 될 수 있기 때문에 잠시 동안 sudo의 요점을 설명하는 좌절 한 슬픔에서 물러날 것입니다 (오픈 소스가 아니기 때문에 감사합니다, Windows). (c) 다른 사람들도 이것에 대해 열정적이라는 것을 보는 것은 정말 멋지다.

나는 그 길을 시작했기 때문에 이것을 제대로하는 것이 얼마나 힘든지 압니다. 그래서 지금 우리를 막는 유일한 것이 UAC 대화창이라면 그렇게하세요. 최소한 이렇게하면 약간의 노력으로 크로스 플랫폼 솔루션을 테스트 할 수 있습니다.

내가 개인적으로 PowerShell에서보고 싶은 것은 Unix sudo에 대한 포괄적 인 지원이지만, 현재와 같은 일부 형태의 "pseudo-sudo"스크립트를 지원하도록 설계되었으며 향후 잠재적 인 실제 Windows sudo입니다. 내 생각은 누군가가 Windows sudo가 궁극적으로 작동하는 방식을 프로토 타입으로 만들었지 만 UAC 제한을 벗어난다면 상당히 간단해야하며, 기본적으로 지금만큼 좋은 것을 제공해야하며, 실제 결과를 얻으면 꽤 좋을 것입니다. 드롭 인 교체 일뿐입니다.

분명히 이것은 누군가가 Unix uid / gid 모델과 Windows sid / acl 모델을 모두 이해하거나 적어도 번역하는 모델을 생각해 내야한다는 것을 의미합니다. 이 사람이 도전을 좋아하기를 바랍니다. 이를 위해서는 MS 내의 터미널 및 Windows 보안 팀과의 대화도 필요합니다.

많은 사람들이 자신의 최선의 해결 방법을 만들고 이와 같은 것을 지원하는 것이이를 수행하는 강력한 방법을 설계하는 데 도움이 될 수 있다고 생각합니다.

사이드 노트-이러한 해결 방법 스크립트를 작성하는 사람은 sudo가 가진 시간 제한 기능을 팝업만큼이나 성가 시게 생각할 수 있습니다.

Start-Process pwsh -NoNewWindow -Credential $cred 에 대해 생각할 수 있습니다. 작동하지 않지만 할 수 있습니다.

분명히 이것은 누군가가 Unix uid / gid 모델과 Windows sid / acl 모델을 모두 이해하거나 적어도 번역하는 모델을 생각해 내야한다는 것을 의미합니다. 이 사람이 도전을 좋아하기를 바랍니다. 이를 위해서는 MS 내의 터미널 및 Windows 보안 팀과의 대화도 필요합니다.

유닉스는 또한 acls를 가지고 있고 windows는 posix 호환성을 가지고 있으며 적어도 그것이 도메인 조인트라면 우리가 사용할 수있는 1 차 그룹 속성도 있습니다 (그리고 posix 속성들). 도메인에 가입 하지 않은 Windows 클라이언트 (또는 지금은 User 가정)에 대해 구현하면됩니다.

따라서 유닉스 및 Windows 권한에 대한 일반 모델은 기본적으로 다음과 같습니다.
소유 사용자 및 일부 예상 ACE (사용자, 그룹 및 기타)가있는 소유 그룹이있는 ACL.

유닉스 권한을 다음과 같이 매핑 할 수 있습니다.
uid => 소유자 SID
gid => 개체를 만든 사용자의 기본 그룹 SID입니다.
사용자 => 제작자 소유자 ID S-1-3-0
그룹 => 크리에이터 그룹 ID S-1-3-1
기타 => 세계 / 모두 S-1-1-0
유닉스의 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과 같은 명령을 실행하면 권한이 디스크에 저장되는 방식을 알지 못한 채 유닉스 시스템에서 작동하기 시작합니다.

@ mmillar-bolis 나는 이미 여기에서 소켓을 사용하는 접근 방식을 제안했습니다 : https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

Start-Process pwsh -NoNewWindow -Credential $ cred에 대해 생각할 수 있습니다. 작동하지 않지만 할 수 있습니다.

업데이트 : .Net Core (그리고 Windows API도 포함)는 동일한 콘솔에 연결된 새 프로세스를 실행할 수 없습니다.

따라서 우리가 사용할 수있는 단일 방법은 상승 된 Windows 서비스입니다. 그러나 보안을 위해 "sudo"별로 이러한 서비스 프로세스를 만들어야합니다.
따라서 솔루션은 향상된 사용자 자격 증명을 사용하여 로컬 호스트에 대한 New-PSSession (또는 PSSession에서 호출)입니다.

@iSazonov 동일한 콘솔에 연결할 수있는 유일한 것 중 하나는 여기에서 이미 언급 한 것입니다. https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

이제 Windows가 유닉스 소켓을 지원하므로 이들 또는 명명 된 파이프를 사용할 수 있으며 권한있는 서비스는 자격 증명의 유효성을 검사하고 항상 실행해야합니다 (* nix oses에 대한 링크 된 게시물에 언급 된대로 suid를 통해 호출되는 것과 비교). .

아마도 lsas는 그러한 인증 API 기능을 제공하기 위해 확장되어야할까요?
이렇게하면 동일한 콘솔에 안전하게 연결하고 입력을 수락하는 동시에 완전한 가장을 얻을 수 있습니다.

@ agowa338 귀하의 제안 "사실상"은 PowerShell 원격입니다. 이미 구현되었습니다.

그러나

따라서 솔루션은 향상된 사용자 자격 증명을 사용하여 로컬 호스트에 대한 New-PSSession (또는 PSSession에서 호출)입니다.

localhost에서는 작동하지 않습니다. AccessDenied 만 발생합니다.

다음 중 하나는 예외입니다.

• UAC가 꺼져 있습니다.
• 관리자 승인 모드를 사용하지 않고 BUILDIN \ Administrator에 연결하려고합니다.
• 프로세스 (Powershell)가 이미 상승했습니다.

@ jborean93에 의한 이유는 다음과 같습니다. https://github.com/PowerShell/Win32-OpenSSH/issues/1308#issuecomment -448430464

따라서 브로커 역할을하는 권한있는 서비스가 필요하거나 API 중 하나를 변경해야하지만 이는 PowerShell / PowerShell 내에서 수행 할 수있는 작업이 아니며 Microsoft 직원이 내부적으로 위임해야합니다.

@ agowa338 언급 한 코멘트는 로컬 Windows API에 대한 것이지, 거기에서 질문이었던 PowerShell 원격이 아닙니다.

@iSazonov : localhost에 powershell 원격 작업을 시도해 보셨습니까? 위에서 설명한 이유 때문에 작동 하지

localhost에 대한 PowerShell 원격은 로컬 컴퓨터에서 상승 된 권한을 얻을 수 없습니다 .

그러나 PowerShell 원격은 localhost를 제외한 네트워크의 다른 모든 호스트에 대한 상승 된 권한을 부여합니다 (도메인 관리자 등의 구성원이라고 가정).

그것은 우리가 창에 sudo를 동등한 필요 이유입니다. PowerShell 원격 기능이 그렇게 작동한다고 생각하는 경우 기능이 이미 존재하므로 문서에 예제를 작성하여이 티켓을 닫을 수 있습니다.

@ agowa338 보안 보호로 인해 작동하지 않습니다. OS 기능이 아닙니다. https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting에 설명 된대로 WinRM을 구성 할 수 있습니다. 참조 한 문제는 SSH에서도 작동한다고 말합니다 (단계는 기사에서 참조).

기능이 이미 존재하기 때문입니다.

요청은 "sudo Remove-Item foo.txt where foo.txt는 root가 소유 함"을 가져 오는 것입니다.
작동하지 않지만 우리는 원할 것입니다.
문제는 언어와 구현의 구문 설탕이라는 두 부분으로 구성됩니다.

제안에 대해 더 많이 생각하면 사용자 당 / 세션 당 / 실행 공간 당 / 범위 당 powershell 컨텍스트가 필요하다는 것을 알게됩니다. 그런 다음 보안 규정 준수 요구 사항을 해결해야하며 기본 구성에서 "액세스 거부"가 발생합니다. 그 후 제안은 이미 구현 된 PowerShell 원격과 동일합니다.

about_Remote_Troubleshooting-PowerShell

보안 보호로 인해 작동하지 않습니다. OS 기능이 아닙니다. 문서에 설명 된대로 WinRM을 구성 할 수 있습니다.

@iSazonov 좀 더 자세히

요청은 "sudo Remove-Item foo.txt where foo.txt는 root가 소유 함"을 가져 오는 것입니다.

비 Windows 시스템의 경우 유닉스 소켓 접근 방식을 사용하여 powershell 원격에 대한 가장 / 승격을 구현할 수 있습니다.

좀 더 자세히 설명해 주시겠습니까? 나는 그 머신과 네트워크의 다른 머신으로 원격으로 이동할 수 있지만 그들 중 어느 것에서도 localhost로 이동할 수 없습니다. 그리고 네, 그 페이지를 읽었습니다.

대부분의 공격은 지역 고도를 목표로합니다. 따라서 모든 구성은 "기본적으로 안전"합니다. WMI, WinRM, IIS 루프백 등-모든 하위 시스템은 로컬 권한 상승을 허용하는 기능을 비활성화합니다.
토론에는 그렇게 중요하지 않습니다. PowerShell 원격 기능이 기본적으로 sudo를 수행하도록 허용하지 않더라도 기본적으로 해제하거나 대화 형 세션 만 허용하도록 구현할 수 있습니다.

Windows가 아닌 시스템의 경우 유닉스 소켓 접근 방식을 사용하여 powershell 원격에 대한 가장 / 승격을 구현할 수 있습니다.

모든 플랫폼에 대해 동일한 UX를 가져야합니다. 실제로 PSRP는 WinRM 또는 SSH 전송을 통해 작동합니다. MSFT는 그들이 SSH를 좋아한다고 말했지만 지난 2 년 동안 눈에 띄는 진전을 보지 못했습니다. 그리고 그들이 _ 가까운 _ 미래에 세 번째 프로토콜을 원할 것이라는 것은 믿기지 않습니다.-너무 많은 작업 (오래된 시스템과의 호환성을 유지해야 할 필요성).

대부분의 공격은 지역 고도를 목표로합니다. 따라서 모든 구성은 "기본적으로 안전"합니다. WMI, WinRM, IIS 루프백 등-모든 하위 시스템은 로컬 권한 상승을 허용하는 기능을 비활성화합니다.
토론에는 그렇게 중요하지 않습니다. PowerShell 원격 기능이 기본적으로 sudo를 수행하도록 허용하지 않더라도 기본적으로 해제하거나 대화 형 세션 만 허용하도록 구현할 수 있습니다.

나는 얼마 전에 그것을 가능하게하려고 노력했고, 이것이 내부적으로 OS에 의해 제한되고 Windows 내부에 깊이 연결되는 응용 프로그램 없이는 어떤 식 으로든 불가능하다는 많은 다른 사람들로부터 반복적으로 들었습니다. 사실 많은 사람들이 위에서 언급 한 윈도우 API 제한을 지적하고 왜 powershell이 ​​그러한 기능을 제공 할 수 없는지에 대한 주장으로 사용했습니다. 그리고 누군가는 루프백 상승이 의도적으로 제거 된 CVE를 참조하기도했습니다. 따라서 그 토끼 구멍을 조금 더 깊이 내려가는 것에 대해 사과드립니다. 그러나 작동하려면 무엇을 구성해야합니까? 그게 어디서나 문서화되어 있습니까?

모든 플랫폼에 대해 동일한 UX를 가져야합니다. 실제로 PSRP는 WinRM 또는 SSH 전송을 통해 작동합니다. MSFT는 그들이 SSH를 좋아한다고 말했지만 지난 2 년 동안 눈에 띄는 진전을 보지 못했습니다. 그리고 그들이 가까운 장래에 세 번째 프로토콜을 원할 것이라는 것은 믿기지 않습니다. 너무 많은 작업 (오래된 시스템과의 호환성을 유지해야 할 필요)입니다.

둘 다 모든 플랫폼에서 작동하므로 두 솔루션 중 하나를 추진해야합니다.

• PSRP : localhost에 대한 SSHing은 Windows 및 Linux에서 승격을 위해 작동하므로 psrp 하위 시스템을 사용하면 이미 올바른 권한이 있으므로 개체 전달을 허용하려면 powershell 계층 만 균일화해야합니다. 권리?
• 유닉스 소켓을 사용하면 powershell 원격과 같은 유사한 기능을 제공 할 수 있지만 작성 당시에는 토큰 스와핑을 수행하기 위해 로컬 시스템으로 실행되는 추가 서비스없이 로컬 권한 상승을 수행하는 것이 어려운 제한이라고 가정했습니다.

따라서 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를 사용하여 시도했는데 예상대로 작동하며 로그온 유형 Network와 함께 상승 된 토큰 ( Mandatory Label\High Mandatory Level )을 제공합니다.

따라서 PSCore에서 우리는 승격을 위해 psrp에 의존 할 수 있습니다 (심지어 명시적인 자격 증명이 전달되는 경우에도 작동하는 Enter-PSSession -HostName localhost 를 통해 로컬에서도 가능합니다.
Enter-PSSession -ComputerName localhost -Credential $foo 가 아닌 경우 ($ foo.Username이 현재 사용자와 동일하더라도)

@ agowa338 여기서 WinRM의 보안 기능을 우회하는 것에 대해 논의해서는 안된다고 생각합니다 (준수 감지 영역입니다). (1) 프로토콜에 관계없이 보안은 동일한 수준으로 유지되어야합니다. 이는 Windows 내부가 작동하는 방식을 고려하여 SSH 루프백이 WinRM과 동일하게 작동해야 함을 의미합니다. (2) PS sudo 구현이 계속 작동해야 함을 의미합니다. 모든 운송.

@iSazonov : 저는 익스플로잇을 요청하지 않았지만이를 활성화하기 위해 구성해야 할 사항 만 요청했습니다. 또한 루프백 상승을 허용하기 위해 WinRM을 구성하는 방법을 알아 낸 유일한 사람이 될 수 있습니다.
나는 그것을 매우 오랫동안 활성화하려고 노력했습니다. 모든 질문 (stackoverflow, reddit, github 문제, ...) "윈도우가 이상 해요", "윈도우가 거기에서 무슨 일을하는지 모르겠어요", "아무데도 문서화되어 있지 않습니다", "윈도우가 제공하지 않습니다 그 기능 ","대신 Linux 사용 ","UAC 비활성화 ","시스템 권한으로 실행되는 브로커 서비스를 작성해야합니다 ". 그래서 당신이 그것을 이해했다면, 당신의 지식을 공유하십시오.

프로토콜에 관계없이 보안은 동일한 수준으로 유지되어야 함을 (1) 표시 할 수 있습니다.

그게 무슨 뜻이야?

이는 SSH 루프백이 Windows 내부의 작동 방식을 고려하여 WinRM과 동일하게 동작해야 함을 의미합니다.

Well SSH에는 백그라운드에서 브로커 역할을하는 시스템 서비스가 있습니다. 그것은 네트워크 액세스 토큰을 제공합니다 ...

(2) PS sudo 구현은 모든 전송에서 작동해야합니다.

정확히 그 이유 때문에 WinRM을 넘지 않습니다. 따라서 루프백 WinRM을 활성화하는 방법에 대한 문서가 필요하다고 말씀하신 것이 사실이라면.

당신이 그것을 이해했다면, 당신의 지식을 공유하십시오.

@ agowa338 MSFT 팀이 보안에 대해 공개적으로 논의하지 말라고 요청했고 CoC를 따릅니다. 이 주제를 자세히 살펴보고자하는 여러분의 열망을지지하지만,이 토론의 일부로 MSFT는이 솔루션을 Windows에 통합하고 보안 규정을 준수하는 방법에 대한 골칫거리입니다.

그것은 누구에게도 도움이되지 않습니다.

그것을 불러내려면 :

• Windows에는 WinRM 내에서 sudo와 같은 기능이 있다고 말합니다.
• 그것이 존재한다는 것과 그것을 활성화 / 비활성화하는 방법은 문서화되어 있지 않습니다.
• 사용 방법을 공개하면 보안 위험이 있습니다.

죄송합니다. 기능이 아닌 백도어처럼 들립니다. 당신 이외의 사람은 사용할 수 없습니다.
또한 모호성을 통한 보안은 과거에도 효과가 없었습니다.

그래서 우리는 현재 구현되지 않았으며 브로커 서비스가 필요합니다.

@ agowa338 MSFT 팀이 결론을 내릴 수 있도록 충분한 정보를 수집했습니다. 보안 문제를 발견하면 수용 가능한 대체 방법을 보여줄 것입니다.

가능했지만 올해 초 https://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/ 패치가 KB4480116 패치 및 후속 누적 업데이트로 패치 LocalAccountTokenFilterPolicy 가 winrm quickconfig 의 기능인 1로 설정되어있는 경우 권한이 부여됩니다 (실제로 WinRM에 필요함).

JEA 엔드 포인트가 영향을받지 않으므로 잠재적으로 자신의 PSSessionConfiguration을 만들고 연결할 수 있다는 메모가 있지만 확인하기 위해 테스트하지는 않았습니다. 개인적으로이 패치는 PowerShell 클라이언트가 localhost에 연결하는 것을 막기 때문에이 패치는 어리석은 일이라고 생각하지만 수행중인 작업을 알고 있으면 쉽게 우회 할 수 있습니다. 예를 들어 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를 우회하는 방법 중 하나는 알려진 LocalAccountTokenFilterPolicy 레지스트리 속성입니다. 이 속성의 명시적인 목적은 네트워크 로그온이 필터링 된 토큰이 아니라 항상 상승되도록하는 것이며,이를 활성화하지 않으면 "루프백"공격을 방지한다고 명시 적으로 나타냅니다.

로컬 관리자 그룹의 구성원 인 사용자를 더 잘 보호하기 위해 네트워크에 UAC 제한을 구현합니다. 이 메커니즘은 "루프백"공격을 방지하는 데 도움이됩니다. 이 메커니즘은 또한 로컬 악성 소프트웨어가 관리 권한으로 원격으로 실행되는 것을 방지합니다.

궁극적으로 이것이 의미하는 바는 Windows에서 비대화 형 방식으로 제한된 권한에서 관리자로 권한을 높일 수있는 공식적인 방법이 없다는 것입니다. Start-Process ... -Verb Runas 를 사용하는 것은 매우 간단하지만 UAC 프롬프트를 표시하려면 대화 형 로그온이 필요합니다. sudo와 같은 메커니즘을 사용하면이 문제를 완화하는 데 도움이되지만 제대로 수행하려면 PowerShell과 관련된 것이 아니라 Windows 자체에서 작업해야합니다. "해결 방법"이 있지만 공식적으로 부르지는 않을 것이며 WinRM 활성화의 알려진 부산물 일뿐입니다.

PowerShell

PowerShell에 영향을주는 Windows 보안 변경 사항 |

PowerShell에 영향을주는 Windows 보안 변경 2019 년 1 월 9 일 최근 (2019 년 1 월 8 일) Windows 보안 패치 CVE-2019-0543은 PowerShell 원격 시나리오에 대한 주요 변경 사항을 도입했습니다. 대부분의 사용자에게 영향을주지 않는 좁은 범위의 시나리오입니다. 주요 변경 사항은 로컬 루프백 원격에만 영향을줍니다.

Mark의 블로그

PsExec, 사용자 계정 제어 및 보안 경계

필자는 Windows XP의 관리자 계정에서 표준 사용자 권한으로 프로세스를 실행하는 쉬운 방법으로 약 1 년 반 전에 PsExec에 -l 스위치를 도입했습니다. 제한된 사용자로 실행 – 쉬운 방법 PsExec이 CreateRestrictedToken API를 사용하여 보안 컨텍스트를 생성하는 방법을 설명했습니다.

Windows 7 엔지니어링

UAC에 대한 업데이트

안녕하세요, Jon DeVaan이 최근받은 UAC 피드백에 대해 이야기를 나눕니다. Windows 7을 마무리하는 대부분의 작업은 피드백에 응답하는 데 중점을 둡니다. UAC 피드백은 엔지니어링 의사 결정 프로세스의 몇 가지 차원에서 흥미 롭습니다. 나는 그 차원을 탐구하는 것이 흥미로운 e7을 만들 것이라고 생각했습니다.

@iSazonov 이러한 제안 중 어느 것도 _ 동일한 콘솔 세션 내에서 _, 특히 UAC_가없는 환경에서 _user-interactive_ 명령 상승을 달성하지 못합니다. 이러한 문제에 대해 Microsoft를 대신하여 발언 할 수있는 것 같습니다. 제가 설명한대로 이러한 기능을 도입하는 데 단순히 관심이 없는지 분명히 말씀해 주시겠습니까?

이 경우 위의 게시물에서 해석했듯이 나머지 사용자는 @parkovski 의 TokenServer 아이디어와 같은 솔루션을 다른 곳에서 찾아야하기 때문에이 스레드를 닫는 것이 현명한 것 같습니다.

이러한 문제에 대해 Microsoft를 대신하여 말할 수있는 것으로 보입니다.

저는 MSFT 회원이 아닌 프로젝트의 커뮤니티 관리자이며 Microsoft를 대신하여 말할 수 없습니다.

그들이 내가 설명한 것과 같은 기능을 도입하는 데 관심이 없는지 명확히 하시겠습니까?

_ 모든 제안에는 가치가 있습니다. 그들 중 누구도 거부되지 않습니다. 토론은 가능한 모든 제안을 수집하기위한 것입니다 ._

현재 저는 우리가 정체되지 않고 앞으로 나아갈 수 있도록 모든 제안을 요약하려고합니다.

내가 본다.
주요 시나리오는 Windows에서 Unix 사용자를 채택하는 것입니다.

• 역사적으로 Unix 사용자는 하나의 콘솔에서 작업하고 sudo는 기본적으로 _same_ 콘솔에서 상승 된 권한으로 작업을 수행하도록 도와줍니다.
• 역사적으로 Windows 사용자는 필요한 경우 상승 된 권한 콘솔로 새 창을 엽니 다. 이것은 다중 창 환경에서 편리하기 때문에 수년 동안 잘 작동합니다. (Windows 사용자는 Windows Core 및 Nano를 고려하여 pssudo의 혜택을받을 수 있습니다.)

따라서 기대치는 다음과 같습니다.

• 의사는 대화 형 세션에서만 작동합니다.
• pssudo가 새 콘솔을 열지 않음 (UAC 창은 Windows에서 허용되며 Windows 보안 및 정신을 깨고 싶지 않습니다)
• 의사 적시 캐시 크레 덴셜
• pssudo는 보안을 위해 세션 상태를 캐시하지 않습니다.
• 가능한 한 동일한 UX가 모든 플랫폼에 있음
• pssudo는 기본 명령을 실행합니다.
• pssudo는 PowerShell 스크립트 블록 / 파일을 실행합니다.

구현 세부 정보 :

• PowerShell 원격은 가장 강력하고 기능적인 솔루션입니다. 이미 구현되어 작동합니다. 다른 사용자는 사용자 / 세션 / 런 스페이스 / 범위 상태에서 PowerShell 스크립트 블록을 실행하기 위해이 기능을 에뮬레이션해야합니다.
• 기본 전송은 WinRM을 기반으로하는 모든 Windows 인프라이므로 WinRM입니다. WinRM에는 약간의 투자가 필요하지만 MSFT는 SOAP를 기반으로하기 때문에이를 원하지 않습니다.
• SSH 전송이 될 수 있습니다. 이것은 여전히 ​​Windows의 표준이 아닙니다. 구현 및 유지 관리에 많은 투자가 필요합니다. 그리고 오래된 시스템을 지원하는 데 문제가 있습니다.
• 유닉스 소켓과 같은 다른 전송. 인프라뿐만 아니라 PowerShell에도 많은 투자가 필요합니다.

@ mklement0 나는 당신이 보통 대단한 일을 여기에서하는 것이 궁금합니다 :-) 당신은 나를 상대로 강탈합니다 :-)

전달 된 명령으로 powershell 인스턴스를 시작하는 권한이 필요한 Windows 바이너리를 작성하지 않는 이유는 무엇입니까? 제대로 작동하려면 콘솔 모드 앱이어야합니다. 그런 다음 Linux의 경우 제공된 명령으로 powershell 인스턴스를 시작하는 권한이 필요한 스크립트를 작성합니다. 이것이 이론적으로 작동하는 것처럼 실제로 작동하면 powershell이 ​​상승 된 권한으로 시작되고 명령을 실행 한 후 종료됩니다.

전달 된 명령으로 powershell 인스턴스를 시작하는 권한이 필요한 Windows 바이너리를 작성하지 않는 이유는 무엇입니까? 제대로 작동하려면 콘솔 모드 앱이어야합니다.

Windows API가이를 방지하고 콘솔 앱이 새 창에서 열리기 때문입니다. 우리는 이미 가능한 해결 방법에 대해 이야기했습니다.

명심해야 할 한 가지는 이것이 어떻게 구현 되든 상관없이 항상 상승 된 프로세스로의 프로세스 홉이 있다는 것입니다. 즉, 파이프 라인에 항상 역 직렬화 된 개체가 있으며 이러한 제한이 적용됩니다. 대부분의 경우 이것은 문제가되지 않지만 cmdlet에 라이브 .NET 개체가 필요한 경우 작동하지 않습니다.

SSH로 JEA를 지원하려면 결국 WinRM의 필요성을 대체하는 일반화 된 데몬 / 서비스가 필요합니다. 그 당시 우리는 파이프 라인의 일부를 높이기 위해 그것을 사용하여 평가할 것입니다.

참고 : https://github.com/gerardog/gsudo

GitHub

gerardog / gsudo

Windows 용 Sudo-새 콘솔 호스트 창을 확장하지 않고 상승 된 실행-gerardog / gsudo

참고 : https://github.com/gerardog/gsudo

GitHub gerardog / gsudo Windows 용

더 나은
http://blog.lukesampson.com/sudo-for-windows

GitHub

gerardog / gsudo

Windows 용 Sudo-새 콘솔 호스트 창을 확장하지 않고 상승 된 실행-gerardog / gsudo

Luke Sampson-Windows를위한 Sudo

Windows 용 Sudo

더 나은

아니.

Gsudo는 매번 암호를 묻는 메시지를 표시하지 않으며 설치 및 사용이 눈에 띄게 빠릅니다.

이 문제는이 티켓뿐만 아니라 관심사로 판단하여 받아 들여 져야한다고 생각합니다 (시간과 조직이 더 많이 주어져야 함을 의미합니다). 현재인지되고있는 기술적 어려움은 적극적인 개입 없이는 해결되지 않을 것이기 때문에 공식적으로이를 업무로 인식하지 않는 것은 옳지 않습니다.

나는 지금 몇 달 동안 gsudo를 사용하고 있으며 항상 전통적인 Windows UAC로 돌아가는 것을 상상할 수 없습니다.

@majkinetor 이 문제는 https://github.com/PowerShell/PowerShell/issues/11343 에서 디자인에 대한 추가 논의를 위해 분리되었습니다.