Powershell: Mendukung sudo<powershell cmdlet=""/>

Bersenandung! Sangat menarik. Tapi, menurut saya perilaku sebenarnya seperti yang diharapkan. Seperti di Windows, kami tidak memiliki perintah seperti sudo.
Tapi, Anda bisa menggunakan 'sudo powershell' dan kemudian menghapus foo.txt (yang dibuat menggunakan 'sudo powershell') kemudian berfungsi saat menggunakan Remove-Item. Tentu saja, ini tidak akan berfungsi dalam izin non-tinggi.

Saya hanya akan menggunakan 'sudo' pada perintah Linux ("sudo nautilus") dari dalam PowerShell.

:)

Bahkan pada Windows, akan lebih baik jika memiliki kemampuan yang sama untuk menjalankan cmdlet sebagai pengguna lain atau yang ditinggikan dan sesuatu yang dapat diandalkan dalam skrip portabel. Mungkin perlu RFC untuk ini.

Fungsionalitas ini akan berguna untuk mengatasi # 3506.

Ini akan menjadi pemblokir untuk mengadaptasi Linux bagi saya jika ini tidak diselesaikan. Kami tidak diizinkan melakukan sudo bash dan juga tidak akan dapat melakukan sudo powershell.

Saya setuju dengan Maximo, kita harus meninggalkan sudo untuk bash dan membuat cmdlet baru untuk melakukan elevasi di PowerShell menggunakan sudo sebagai perancah pada fungsionalitas yang diharapkan.

@dantraMSFT telah menyelidiki hal ini, Dan dapatkah Anda memberikan pembaruan tentang pemikiran terkini untuk ini?

@pixelrebirth Dapatkah Anda memberikan detail lebih lanjut tentang apa yang Anda harapkan? Apakah Anda mengharapkan eksekusi sederhana dengan menunggu, pengalihan keluaran, atau pengalihan pipeline?
Beberapa contoh penggunaan akan berguna juga.

@dantraMSFT Demi argumen saya akan memanggil sudo baru seperti cmdlet: Invoke-Elevated
Beginilah cara sudo bekerja dan akan diterjemahkan ke Invoke-Elevated dengan cara PowerShell

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

Dalam contoh ini, semua yang ada di scriptblock akan dieksekusi dan kemudian disalurkan ke Get-SomeCmdlet NON yang ditinggikan
Cred bisa menjadi pengguna yang berbeda atau diri Anda sendiri sebagai pengguna yang ditinggikan (izin perlu disimpan di suatu tempat seperti file sudoers alias daftar putih)

Logging harus diaktifkan, secara default untuk contoh di mana Invoke-Elevated dijalankan:
Pengguna | Perintah | DateTime atau pencatatan format serupa

Mungkin beberapa di antaranya diperpanjang atau diubah nanti, tetapi inilah yang akan menghapus pemblokir saya

Ini juga harus bekerja seperti:

Get-ChildItem ./test | Invoke-Elevated -command {Remove-Item -force}
Di mana kredensial adalah pengguna Anda saat ini dan itu hanya meminta kata sandi ...

Get-ChildItem NON dinaikkan, Remove-Item dinaikkan dalam contoh ini

Saya berada di panggilan komunitas hari ini menanyakan tentang hal ini, tetapi istri saya terluka selama penjelasan tentang tantangan untuk itu dan saya banyak melewatkannya. Bisakah Anda memberi catatan di sini agar saya dapat menyampaikannya kepada bos saya?

Saya akan membantu bagaimanapun mungkin dan memberikan tekanan di mana pun saya perlu.

@pixelrebirth harap dia baik-baik saja! Kami akan merekam panggilan tersebut dalam satu atau dua hari ke depan, jadi Anda bisa menyusul jika mau.

Ringkasan dasarnya adalah sudo powershell -c "invoke-foo" dari shell lain, tetapi itu jelas tidak bisa diterapkan.

@dantraMSFT : saat Anda mengerjakan penyelidikan, mungkin memposting beberapa status untuk memastikan bahwa setiap orang memahami pengorbanan dengan pendekatan yang berbeda?

Ini mungkin tampak jelas, tetapi mungkin lihat kode sumber sudo dan lihat bagaimana mereka mengelolanya - mungkin memerlukan beberapa pengkodean tingkat rendah. Saya berharap saya memiliki pemahaman kode yang lebih dalam untuk membantu.

Dia baik-baik saja, dia merasakan di pinggul operasinya. Terima kasih atas tanggapan yang cepat untuk ini. Saya sedang mengerjakan sedikit pekerjaan retas yang akan saya posting di sini jika saya berhasil.

@pixelrebirth Untuk referensi, sudo menggunakan bit setuid, lihat https://unix.stackexchange.com/a/80350/86669 untuk detailnya. Mungkin akan menjadi ide yang buruk untuk mengaturnya di seluruh cangkang.

Sudo Windows asli harus dimiliki (jadi masalahnya mungkin bukan di sini, meskipun opsi yang hanya dapat digunakan melalui Powershell dapat diterima oleh saya). Saya telah menggunakan Powershell sejak awal dan telah melihat 99 varian skrip sudo, seperti Invoke-Elevated atas (atau milik saya yang saya gunakan setiap hari). Menyertakan cmdlet seperti itu di Powershell akan menjadi langkah maju, namun, mereka semua merasa tidak praktis jika dibandingkan dengan cara kerjanya di Linux.

Salah satu hal yang mengganggu bagi saya adalah ia memulai jendela shell baru (bukan di linux) yang ingin saya lihat diimplementasikan di Powershell / Windows, tidak yakin apakah ini secara teknis mungkin dilakukan di Windows.

Meskipun saya menyukai ide cmdlet lain ("Invoke-Elevated") yang mungkin dapat digunakan di Windows, tetapi saya tidak mengerti mengapa tidak tetap membuka PowerShell dengan 'sudo' jika Anda perlu membuat skrip untuk dijalankan dengan high hak istimewa?

Terutama Jika Anda mengotomatiskan tugas yang pada akhirnya akan dijadwalkan untuk dijalankan dengan semacam kredensial hak istimewa yang tinggi.
:)

Karena itu bukan alur kerja biasa. Anda tidak 'sudo' dan tinggal di sana selamanya, Anda menggunakan perintah khusus sudo dan tinggal di dunia non-sudo. Tidak ada cara cepat untuk melakukannya di Windows dan PowerShell sendiri sangat lambat untuk memulai, terutama dengan beberapa elemen profil yang disertakan.

Dalam sesi setiap hari yang khas saya sudo 20 kali perintah tertentu, yang lain menjalankan tanpa hak. Itulah inti dari sudo, untuk meningkatkan hak istimewa hanya jika diperlukan dan mungkin diperlukan cukup sering.

Alur kerja saya adalah, jalankan perintah, mengeluh tentang hak istimewa, saya sudo -L yang akan menjalankan perintah terakhir lagi dengan hak istimewa. Karena posh sangat lambat untuk memulai, saya hanya menjalankan shell admin dan terus-menerus hidup di dalamnya, jelas bukan ide yang bagus.

Terima kasih @majkinetor!
:)

Sudo harus berupa varian CLI dari perintah UAC. Windows, sampai saat ini, tidak pernah ramah CLI, tetapi sekarang saya pikir kita membutuhkan ini. Waktunya telah tiba ketika Anda dapat melakukan 100% hal-hal Windows di shell saja - Saya pribadi hanya menggunakan shell dan browser, hampir tidak ada yang lain.

@ Majkinetor : Sejauh yang saya tahu, satu-satunya cara untuk meluncurkan proses yang ditingkatkan adalah melalui prompt UAC.
FWIW: Anda dapat melakukannya di windows tanpa perubahan PowerShell menggunakan ShellExecuteEx.
Namun, jika Anda mengharapkan untuk mengalirkan kembali hasilnya; itu cerita yang sangat berbeda.

Sejauh yang saya tahu, satu-satunya cara untuk meluncurkan proses yang ditinggikan adalah melalui prompt UAC.

Aplikasi tertentu dapat dikecualikan dari UAC yang menurut saya dapat menangani ketinggian dengan caranya sendiri.

Ingin menawarkan solusi / solusi saya untuk Sudo di Windows. Umpan balik / kritik akan diterima. Jika tidak pantas untuk memposting hal semacam ini di sini saya mohon maaf sebelumnya.

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

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

Ada tiga fungsi dalam Modul Sudo:

• Sesi Sudo Baru
• Hapus-SudoSession
• Start-SudoSession

Start-SudoSession (alias "sudo") adalah untuk perintah satu kali yang perlu Anda tingkatkan. Ini akan meminta kredensial dan memberi Anda prompt UAC sebelum menjalankan perintah.

.CONTOH

$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 jika untuk membuka ElevatedPSSession di mana perintah yang ditinggikan dapat disuntikkan. Idenya adalah bahwa dalam skrip yang lebih panjang dengan beberapa operasi yang memerlukan elevasi, Anda membuat ElevatedPSSession di awal dan menerima prompt UAC SEKALI, lalu menyuntikkan perintah yang ditinggikan tersebut menggunakan Invoke-Command ke ElevatedPSSession tersebut saat diperlukan.

.CONTOH

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}

Akhirnya, Remove-SudoSession menghapus ElevatedPSSession yang dibuat oleh fungsi New-SudoSession. Idenya adalah menempatkan ini di akhir skrip Anda, di mana Anda akan menerima prompt UAC. Jadi secara total, untuk menjalankan sejumlah operasi yang ditinggikan dalam skrip tertentu, Anda hanya mendapatkan dua perintah UAC - satu untuk membuka ElevatedPSSession dan satu lagi untuk menutupnya. Hapus-PSSession penggunaan:

.CONTOH

$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

Di bawah tenda, inilah yang dilakukannya dari sesi PowerShell Non-Elevated (jika sesi sudah dinaikkan, itu tidak melakukan apa-apa):

• Cek untuk memastikan WinRM / WSMan diaktifkan dan dikonfigurasi untuk mengizinkan Otentikasi CredSSP (jika tidak maka
  perubahan konfigurasi dibuat)

• Memeriksa Objek Kebijakan Grup Lokal ...

  Konfigurasi Komputer -> Template Administratif -> Sistem -> Delegasi Kredensial -> Izinkan Pendelegasian Kredensial Baru

  ... untuk memastikannya diaktifkan dan dikonfigurasi untuk mengizinkan koneksi melalui WSMAN / LocalHostFQDN

• Membuat PSSession yang Ditinggikan menggunakan cmdlet New-PSSession

• Menjalankan ekspresi yang diteruskan ke parameter -Expression di Elevated PSSession

• Menghapus PSSession yang Ditinggikan dan mengembalikan semua perubahan yang dibuat (jika ada) ke Kebijakan Grup Lokal dan konfigurasi WSMAN / WinRM.

EDIT: Salah ketik contoh Hapus-SudoSession yang diperbarui.

@pldmgg Saya tidak melihat lisensi apa yang digunakan untuk kode Anda sehingga kami bahkan tidak dapat melihat apa yang telah Anda lakukan. Bisakah Anda menambahkan file LISENSI? MIT akan menjadi yang paling ramah dan mengizinkan kami menggunakan kode Anda atau mengambilnya. Terima kasih!

@pldmgg Menindaklanjuti apa yang @ SteveL-MSFT sebutkan, panduan hebat untuk membantu Anda melalui proses ini adalah https://choosealicense.com/.

tl; dr - Sulit untuk salah dengan lisensi berikut:

• Apache 2.0
• MIT

Keterangan lebih lanjut

Apache 2.0 memiliki beberapa kekuatan tambahan di atasnya dibandingkan MIT, tetapi secara keseluruhan, mereka sangat permisif dan mudah digunakan dengan lisensi open source lainnya dan sangat ramah bisnis. Jika Anda memilih lisensi copyleft (GPL), kode tidak dapat digunakan dengan alat lain tanpa alat lain tersebut pindah ke lisensi GPL (juga dikenal sebagai lisensi viral - LGPL menjadi pengecualian di sini, di mana modul / binari berlisensi LGPL dapat ditempatkan di samping alat lain tanpa memerlukan perubahan lisensi ke kode lain).

@pldmgg juga, sangat, sangat keren!

@ferventcoder Terima kasih atas referensi https://choosealicense.com! Seperti yang mungkin kalian duga (+ @ SteveL-MSFT), saya tidak begitu yakin lisensi apa yang harus dipilih. Saya memperbarui seluruh repo misc-powershell saya untuk menggunakan Apache 2.0, dan saya memperbarui Sudo.psd1 untuk merujuk Apache 2.0 (di repo git saya dan juga Galeri PowerShell). Semoga ini bisa bermanfaat bagi orang-orang! Semua saran / kritik diterima!

@ SteveL-MSFT Dapatkah Anda menggunakannya jika lisensinya adalah Apache 2.0? Jika Anda membutuhkannya menjadi MIT, beri tahu saya dan saya akan memperbarui.

@pldmgg Masalah terbesar saya dengan solusi Anda adalah penggunaan CredSSP. Itu adalah metode yang kurang aman untuk penanganan kredensial dan menurut saya banyak risiko terkena batas UAC.

Mengutip dari Powershell Magaize ,

"Merupakan ide yang buruk untuk menggunakan CredSSP untuk mengotentikasi ke workstation pengguna menggunakan akun administrator domain; pada dasarnya Anda memberikan kunci ke kerajaan."

"Jangan menaruh kredensial kepercayaan tinggi pada komputer dengan kepercayaan rendah"

Inti dari UAC adalah tentang tidak mempercayai aplikasi di komputer. Meskipun saya mungkin menyetujui perintah sudo yang akhirnya menjalankan malapetaka di komputer saya, biasanya itu tidak akan memiliki kredensial saya. Jika perintah sudo sekarang memiliki akses yang jelas ke kredensial domain saya, itu bisa melakukan lebih banyak kerusakan dalam membahayakan jaringan saya.

Dapatkah solusi Anda berfungsi tanpa CredSSP? Jika tidak, masalah apa yang Anda coba selesaikan dalam menggunakan CredSSP? Informasi tersebut dapat berguna bagi tim PowerShell untuk menemukan solusi yang lebih aman.

@pldmgg Saya yakin Apache 2.0 sudah cukup. Terima kasih!

@ dragonwolf83 Ini adalah masalah umum. Saya benar-benar mengemukakan seluruh argumen saya bahwa tidak apa-apa dalam situasi khusus ini di utas ini:

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

Tapi, untuk meringkas, saya pikir tidak apa-apa di sini karena:

• Ini terhubung ke localhost (bukan remote)

• Sejak Windows 8.1 / Server 2012R2, CredSSP tidak lagi mengirim sandi dalam teks biasa

• Remote Desktop Protocol masih rentan terhadap serangan pass-the-hash, seperti CredSSP, jadi jika Anda mengkhawatirkan hal itu untuk CredSSP, Anda juga harus mengkhawatirkannya untuk RDP. (Tentu saja, ada mode Admin Terbatas RDP atau "Penjaga Kredensial" baru)

PS Artikel ini telah menjadi referensi goto saya untuk PowerShell Security (dan di situlah saya belajar tentang Credential Guard) .. Saya sangat merekomendasikannya.

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

Untuk 6.0.0, saya pikir di mana kita akan berakhir adalah:

Fungsi skrip bernama sudo yang hanya ada di Linux (kami menunda dukungan elevasi Windows). Jika argumennya adalah cmdlet / scriptblock, maka sudo PowerShell dengan argumen tersebut. Ini berarti bahwa untuk saat ini, objek pipelining tidak akan berfungsi. Jika argumennya adalah perintah asli, kami langsung meneruskannya ke sudo.

Setelah 6.0.0, pada akhirnya kami ingin mendapatkan pengalaman seperti:

Get-Item foo.txt | sudo Remove-Item

dan berfungsi di Windows dan Linux. cc @ joeyaello

Berdasarkan diskusi @ PowerShell / powershell-committee, ini tidak diperlukan untuk 6.0.0 dan rekomendasinya adalah berinvestasi dalam cmdlet tipe Invoke-AsUser

Untuk mengubah elevasi secara umum, Anda memerlukan sesuatu dengan bit setuid di bawah UNIX dan sudo itu sendiri. sudo adalah biner khusus yang tidak dapat dengan mudah ditiru dan tidak boleh ditiru demi keamanan. Harap biarkan sudo yang sebenarnya digunakan untuk meluncurkan PowerShell sementara yang menjalankan perintah yang dimaksud. Juga, melakukan sudo ke seluruh shell agak tidak aman mengingat orang mungkin lupa shell terbuka di server jarak jauh. sudo memiliki mekanisme untuk melupakan bahwa pengguna meningkat setelah beberapa menit yang melindungi mesin dalam jangka panjang. Resolusi untuk masalah ini akan memungkinkan lebih banyak orang menggunakan PowerShell dalam produksi di server Linux. Saat ini, PowerShell akan tetap menjadi hal baru sampingan karena keamanan adalah yang terpenting dalam produksi.

@borgdylan hari ini, Anda dapat melakukan sudo pwsh -c foo dalam PowerShell Core (atau hanya sudo nativecmd ). Saya pikir keinginannya adalah untuk dapat melakukan sudo cmdlet dalam sesi PowerShell Core yang ada. Kami tidak mencoba membuat ulang sudo sini, tetapi memiliki beberapa gula sintaksis untuk membuatnya lebih mudah digunakan.

Dengan # 1527 dan masalah ini semakin didorong ke belakang tonggak sejarah, saya mulai bertanya-tanya: Apakah semua orang benar-benar nyaman masuk ke sesi root untuk melakukan hal-hal admin? Praktis tidak ada cara mudah untuk menjalankan perintah PowerShell saat PS terlibat dengan cara apa pun.

@MathiasMagnus Saya belum menguji ini secara menyeluruh, tetapi Anda dapat mengonfigurasi perintah umum atau berulang kali digunakan untuk tidak memerlukan kata sandi pada sudo. Untuk menguji saya menambahkan ini dengan visudo:

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

Saya kemudian dapat menelepon sudo pwsh -c 'cat /etc/sudoers' melalui sesi remote PowerShell SSH. Bergantung pada bagaimana Anda melakukan keamanan Anda dan apa yang sebenarnya Anda konfigurasikan di sudoers (misalnya, All=(ALL:ALL) agak terbuka ...) ini bisa aman atau berbahaya.

Jika Anda ssh ke Linux (yaitu ke bash shell alih-alih PowerShell SSH remoting) Anda dapat menjalankan sudo dengan kata sandi normal yang meminta dalam pwsh sejauh yang saya tahu.

Bukan terlalu banyak sehingga tidak mungkin, hanya saja solusi saat ini dilengkapi dengan beberapa bagasi.

@MathiasMagnus # 1527 masih ditargetkan untuk 6.1.0 karena tidak ada solusi yang baik untuk itu. Untuk cmdlet, masalah utamanya adalah komplikasi pemipaan ke / dari cmdlet sudo'd. Untuk operasi tunggal sudo pwsh -c dapat digunakan. Tentu saja jika seseorang dari komunitas mengajukan PR, kami akan dengan senang hati menerimanya.

Di Windows, ini sekarang menjadi masalah yang menurut saya tidak dapat diselesaikan tanpa tidak meningkatkan koneksi ssh, yang kemudian membutuhkan cara untuk meningkatkan dari baris perintah.

Saya tahu mudah untuk membicarakan hal-hal yang tidak berfungsi dan tidak mengambil tindakan, tetapi keahlian saya ada di tempat lain. Saya sebagian besar berkontribusi pada pustaka C ++ dan GPGPU dan Vcpkg melakukan banyak port CMake. Saya belum pernah menulis C # dan saya rasa saya tidak akan memiliki kapasitas untuk itu. Namun saya mengelola sekelompok kecil ~ 12 mesin. Itu di perbatasan dapat dikelola dengan tangan, tetapi kemampuan sudo hilang sama sekali, itu jika saya tidak bermaksud membuat login untuk pengguna root di Ubuntu, sesuatu yang tidak disukai. DSC Core akan menjadi solusi, tetapi meskipun telah diumumkan setahun yang lalu, baru-baru ini telah ditunda tanpa batas waktu.

PowerShell Core di Linux seperti saat ini berdiri agak terjebak antara cara otomatis melakukan sesuatu dan gaya ad-hoc yang akrab bagi sysadmin Linux. Saya berharap seseorang akan meluangkan waktu untuk menghadiri masalah ini.

@MathiasMagnus ini adalah sesuatu yang diinginkan semua orang, tetapi bukan masalah sederhana untuk dipecahkan. Perhatikan bahwa menggunakan sudo terhadap perintah asli berfungsi dengan baik, itu benar-benar tidak tersedia untuk menjalankan sudo melawan cmdlet. Solusinya adalah dengan memanggil pwsh dalam pwsh:

sudo pwsh -c hapus-item sesuatu

Komplikasi utamanya adalah ketika itu adalah sesuatu di dalam pipeline:

dapatkan-item foo * | sudo hapus-item

@ SteveL-MSFT Setidaknya konsepnya tidak terlalu rumit. Tolong beritahu saya apa yang Anda pikirkan.

Kami hanya membutuhkan kombinasi sudo, su dan binari login, untuk menangani semua kasus.

Itu perlu dilakukan:

• Buat soket unix untuk callback dan hanya izinkan pengguna tujuan mengaksesnya.
• Memvalidasi bahwa penelepon diizinkan mengakses sudo (menurut saya seseorang dapat dengan mudah menyalin kode sumber su , sudo dan login )
  
  
  
  • Jika / etc / sudoers ada, itu perlu diurai
    
    
    
    
    
    • Hanya perintah khusus
    
    
    
    • Dengan menggunakan kata sandi pengguna tujuan
    
    
    
    • Tanpa memvalidasi kredensial (tanpa kata sandi)
    
    
    
  
  
  • Jika tidak, seseorang perlu memanggil pem untuk memeriksa apakah pengguna "mengetahui" kredensial untuk root pengguna secara langsung.
  
  
  • Jika dia juga tidak mengetahui kredensial pengguna tujuan, tolak akses dan berikan pengecualian di PowerShell.
  
  
• Jika validasi berhasil, kita perlu mengganti konteks pengguna menjadi root, atau pengguna tujuan.
• Setelah kami mengganti konteks pengguna, proses baru perlu membangun komunikasi kembali ke PowerShell asli yang berjalan dengan menghubungkannya ke soket unix.
• Jika pengguna memasukkan "keluar", kami memberi sinyal melalui soket unix, bahwa kami sudah selesai dan saat kami keluar, pengguna secara otomatis akan kembali ke hak pemanggil, jadi kami hanya memerlukan PowerShell hosting untuk menampilkan prompt atau menjalankan perintah berikutnya petunjuk.
• Jika sebaliknya, PowerShell host berakhir, soket unix ditutup dan PowerShell yang ditinggikan harus menghentikan eksekusi dan menghentikan, sama seperti jika seseorang menutup terminal.

Alur eksekusi akan terlihat seperti ini:
PWSH (membuat socket /proc/self/change-user.socket) => PWSH-SU (dipanggil dengan socket dan tujuan pengguna sebagai parameter; PWSH-SU diatur suid untuk dijalankan sebagai root itu sendiri) => PWSH sebagai pengguna tujuan terhubung ke soket unix.

Bagian yang paling memakan waktu adalah membiarkan PowerShell terhubung secara internal melalui soket unix. Hanya mengarahkan input dan output linke aplikasi unix lain tidak cukup, karena kita berurusan dengan objek dan tidak hanya dengan string saat memanggil pipa.

Mengapa menggunakan ketiga biner?
sudo diperlukan untuk memungkinkan banyak pengguna beralih ke konteks root tanpa kehilangan kemampuan diaudit .
su digunakan untuk beralih ke pengguna lain dengan menggunakan kredensial pengguna tujuan.
login digunakan untuk membuat sesi login baru.
Memiliki semua fungsi ini juga di PowerShell dapat berguna dalam banyak kasus, dibandingkan hanya memiliki satu.

Menggunakan pipa dapat membuat ini bekerja pada Windows juga dengan cara yang tidak terlalu mengejutkan dan lebih nyaman - Saya benci bahwa saya mendapatkan shell lain dengan semua skrip "sudo" + klik UAC tetapi dengan pipa seperti ini dapat dilakukan dalam shell yang sama saja seperti di linux dengan berkomunikasi melalui pipa dengan penerjemah lain yang sudah berjalan sebagai admin dan mungkin menerapkan beberapa hal sudo nyata (batas waktu cepat misalnya atau file sudoers dengan perintah sebagai alternatif untuk titik akhir PowerShell kustom)

Saya sangat senang melihat pemikiran tentang ini, tetapi sejauh implementasi yang sebenarnya, menurut saya kita sudah sedikit maju dari diri kita sendiri. Hal pertama adalah sistem membutuhkan cara untuk membuat proses yang ditinggikan, utas, apa pun dari yang tidak terkait. Tak satu pun dari masalah cmdlet yang benar-benar dapat diselesaikan jika kita tidak dapat membuat instance PowerShell yang ditinggikan untuk memulai, tanpa melalui UAC. IMO, skenario pertama yang akan dibahas di sini harus - Anda memiliki sesi SSH terbatas - bagaimana Anda menjalankan exe biasa dengan izin admin?

Saya mulai bereksperimen dengan ini di sini (saat ini rusak karena saya telah memfaktorkan ulangnya, tetapi konsepnya berfungsi), tetapi saya tidak berpikir aplikasi pihak ketiga adalah solusi sebenarnya. Saya ingin melihat Windows mengirimkan exe 'sudo' terlebih dahulu. Ini bisa sesederhana mengaktifkan runas untuk membuat proses yang ditinggikan dengan prompt kredensial, tetapi tanpa langkah pertama ini semua teoritis.

Tak satu pun dari masalah cmdlet yang benar-benar dapat diselesaikan jika kita tidak dapat membuat instance PowerShell yang ditinggikan untuk memulai, tanpa melalui UAC

Salah satu kemungkinan untuk melakukan ini melibatkan penggunaan tugas terjadwal dengan opsi 'jalankan dengan hak istimewa tertinggi'.

Ya, tetapi untuk membuatnya, Anda harus sudah memiliki izin admin, bukan? Itulah yang dilakukan psexec. Sejauh yang saya tahu, saat ini, Anda harus melalui UAC. Saya ingin melihat perubahan itu, dan dengan semua sesi SSH yang ditingkatkan, ini semacam masalah keamanan. Jika beberapa perangkat lunak samar mencoba melakukan SSH ke mesin Windows saya, katakanlah dari komputer lain tempat saya menyiapkan kunci pribadi (atau skenario loopback), perangkat lunak tersebut dapat melakukan apa pun yang diinginkan.

@parkovski Solusi saya adalah Linux / MacOS dan semua OS * NIX lainnya saja. Windows tidak mendukung SUID dan GUID.
Karena sudo saat ini juga tidak ada di Windows, itu di luar cakupan masalah ini bagi saya.

Dan untuk mengatasi masalah UAC, windows harus mengimplementasikan SUID dan GUID di masa mendatang. Segala sesuatu yang lain hanyalah solusi kotor untuk masalah lama ...

Ya, tetapi untuk membuatnya, Anda harus sudah memiliki izin admin, bukan?

Benar, tapi tidak memicu UAC popup.

UAC juga dapat dilewati secara resmi dengan Toolkit Kompatibilitas Aplikasi Microsoft.

Windows tidak mendukung SUID dan GUID.

Windows tidak harus mendukungnya dan konsep tidak valid pada OS itu.
Model izinnya didasarkan pada ACL dan tidak ada kepemilikan grup tunggal.

Ini juga tidak harus berupa replika sudo penuh di windows, hanya cara yang lebih ramah untuk menjalankan perintah admin.

Saya pikir tidak apa-apa untuk menunda dukungan Windows karena pengguna Windows mungkin terbiasa membuka sesi PowerShell yang ditinggikan hari ini sementara pengguna Linux berharap untuk menjalankannya sebagai non-root dan sudo sesuai kebutuhan. Kami hanya ingin memastikan desain apa pun tidak menghalangi dukungan Windows di masa mendatang. Saya juga mungkin akan fokus pada mengaktifkan sudo untuk root daripada pengguna sewenang-wenang untuk menyederhanakannya dan saya yakin ini adalah 90 +% dari penggunaan.

@ SteveL-MS

mungkin juga akan fokus pada mengaktifkan sudo untuk root daripada sembarang pengguna

Saya pikir ini tidak akan membuat perbedaan besar, tetapi memberikan pengalaman su / sudo lengkap untuk abstrak yang saya uraikan di atas , karena mengalihkan konteks pengguna ke root hampir sama dengan beralih ke pengguna lain.

Saya pikir tidak apa-apa untuk menunda dukungan Windows karena pengguna Windows mungkin terbiasa membuka sesi PowerShell yang ditinggikan hari ini

Mayoritas orang yang bekerja dengan saya hanya menonaktifkan UAC jika mereka bisa.

Sayangnya, itu sebenarnya bukan pilihan di banyak lingkungan, dan saya sangat meragukan MS akan sepenuhnya dan membuang UAC. 😕

Masalah ini bukan tentang UAC. Tetapi dari sudut pandang saya, itu harus dibuang seluruhnya dan diganti dengan dua akun yang ketat, satu admin satu pengguna (dan satu admin tidak dapat digunakan untuk logon) filosofi (instalasi default memaksa Anda untuk membuatnya) atau untuk konsep yang sama * yang dimiliki NIX, Anda mulai sebagai pengguna dan meningkatkan sesuai kebutuhan dengan menggunakan sudo dan SUID / SGID-Flags.

Saya baru saja menambahkan yang berikut ini ke $profile . Saya membahasnya lebih detail di https://stackoverflow.com/a/56265080/118098

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

Setidaknya secara sepintas lalu, ini bekerja untuk saya, dan memungkinkan "sudo". Ini tidak mencakup kasus" dapat melakukan sudo cmdlet dalam sesi PowerShell Core yang ada "per https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -354853084

Namun, saya bertanya-tanya betapa pentingnya memberikan konteks yang ditinggikan ke seluruh sesi perintah pemanggilan. Di shell lain, sudo masih menjalankan perintah yang disediakan dalam konteks baru.

Saya telah menerapkan sudo dasar yang berfungsi dengan baik untuk menjalankan perintah sebagai administrator di Windows. Saya tidak yakin apakah ini juga akan berfungsi di linux / mac, karena saya tidak tahu apakah "RunAs" terangkat dengan benar atau tidak di platform tersebut.

Sunting profilmu:

PS > notepad $PROFILE

Tambahkan fungsi sudo :

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

Kemudian panggil di cangkang Anda. Mendukung cmdlet, file yang dapat dieksekusi, apa pun yang biasanya dapat diketik ke dalam prompt 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

Jika Anda ingin meneruskan variabel atau ekspresi yang akan dievaluasi pada waktu proses, daripada dievaluasi sebelumnya, bungkus dengan tanda kurung. Sebagai contoh:

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

Hapus "-NoExit" dari fungsi sudo jika Anda ingin jendela administrator ditutup setelah selesai.

@vsalvino Ini adalah solusi yang berguna saat GUI tersedia dan berguna untuk sementara waktu, tetapi ini masih bukan sudo nyata karena tidak berfungsi tanpa akses GUI. Dalam shell jarak jauh (ssh), secara harfiah satu-satunya cara untuk membuat ini berfungsi adalah layanan dan klien seperti yang saya coba tunjukkan di sini .

Untuk mengatasi beberapa saran umum, karena percayalah, saya telah melihat setiap kemungkinan:

• Menonaktifkan UAC bukanlah solusi. Ini adalah solusi yang dapat dibuat sebagai pilihan pribadi tetapi ini bukan solusi umum untuk masalah ini.
• Apa pun yang muncul UAC (setiap skrip "sudo" yang pernah saya lihat) bukanlah solusi, termasuk melakukannya sekali untuk memulai sesi jarak jauh yang ditinggikan.
• Apa pun yang membutuhkan GUI _at all_ bukanlah solusi. Mari kita asumsikan kita menggunakan ssh di sini dan GUI tidak tersedia.
• Apa pun yang memerlukan perubahan besar pada Windows bukanlah solusi. Kami tidak dapat mengandalkan UAC berubah menjadi sesuatu yang lebih baik.
• Bahkan biner bertanda tangan dari Microsoft bukanlah solusi, karena itu tidak akan berfungsi ketika UAC disetel ke tinggi (saya salah pada wsudo readme; saya akan memperbaikinya nanti).
• Satu-satunya solusi nyata untuk sudo di Windows adalah layanan yang meningkatkan proses pengguna pada otentikasi yang berhasil. Saya ingin mendengar ide-ide lain tetapi harap lakukan riset Anda terlebih dahulu.

Pada dasarnya, seseorang harus melakukan banyak pekerjaan, bukan sebaliknya. Apa yang kami inginkan adalah sesuatu yang, setelah PowerShell mendukung ini di Unix, merupakan pengganti pengganti di Windows, dan berfungsi seperti yang Anda harapkan sudo berfungsi (tanpa GUI, tanpa UAC).

Bisakah kami mengklarifikasi ruang lingkup masalah ini terlebih dahulu? Saya pikir banyak orang sedang membicarakan topik yang berbeda sekarang.
Apakah masalah ini:
a) Tentang menerapkan sudo dalam PowerShell untuk sistem linux / mac?
b) Menerapkan replika sudo ke windows?
c) Izinkan untuk meningkatkan hak saat psremoting?
d) Izinkan meniru identitas pengguna lain di windows?
e) Izinkan untuk beralih dari akun pengguna tanpa hak ke akun pengguna dengan hak istimewa?
f) sesuatu yang sama sekali berbeda?

Untuk a) https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067
Untuk b) Sama seperti a (windows juga memiliki soket unix), tetapi sebagai pengganti suid biner, ia perlu dimunculkan oleh layanan (berjalan di dalam pengguna yang memiliki hak istimewa "bertindak sebagai bagian dari sistem operasi" misalnya sistem pengguna) dan layanan itu juga perlu memeriksa hak istimewa. Atau terapkan konsep SUID / GUID di windows.
Untuk c) tidak diperlukan Anda sudah memiliki hak tertinggi saat melakukan remote. Tidak ada pemisahan hak istimewa saat mengakses host jarak jauh (Ada juga beberapa bypass UAC loopback localhost yang bekerja dengan cara ini).
Untuk d) Juga pendekatan dari a / b dapat diambil, tetapi saya tidak tahu bagaimana seharusnya bekerja ketika mencoba mengakses sumber daya jaringan, tanpa mengetahui kredensial pengguna atau membuat backend otentikasi windows / direktori aktif baru.
Untuk e) Sama seperti b, tetapi pemeriksaan kredensial juga diperlukan, sebagai alternatif, api runas dapat dilonggarkan untuk memungkinkan seseorang yang mengetahui nama pengguna dan kata sandi untuk mendapatkan token pengguna baru dan tetap mengontrol proses itu. (Tidak mungkin mempertimbangkan konsep dan pertimbangan keamanan UAC, jadi kami kembali ke b).

IMO masalah ini seharusnya tentang penerapan sudo di PowerShell di mana fungsionalitas yang mendasarinya sudah ada. Diskusi tentang setara sudo untuk Windows mungkin lebih sesuai dalam masalah terminal ini .

Diskusi tentang setara sudo untuk Windows mungkin lebih sesuai dalam masalah terminal ini.

Mengapa aplikasi terminal menjadi tempat yang lebih baik untuk mendiskusikan sudo, mengingat itu hanyalah frontend lain dari dunia CLI? Dengan logika yang sama, Anda dapat mengajukan tiket di repositori ConEmu.

IMO masalah ini seharusnya tentang penerapan sudo di PowerShell di mana fungsionalitas yang mendasarinya sudah ada.

Salah satu poin dari Powershell berikutnya adalah masalah kompatibilitas yang kurang antara sistem yang menggunakannya. Mengenai itu, melakukan sesuatu hanya pada sistem X adalah IMO tidak dapat diterima.

Saya sebagai pengguna CLI tidak peduli jika sudo adalah linux sudo penuh menggunakan file suders atau beberapa windows. Sudo hanyalah sebuah antarmuka untuk fitur elevasi dari OS. Antarmuka seperti itu dapat dibuat untuk bekerja hampir sama tanpa memandang 'backend'.

Jika tidak, titik @parkovski tentang singkatan GUI - Saya hanya akan menambahkan Windows Core di antara alasannya.

Mengapa aplikasi terminal menjadi tempat yang lebih baik untuk mendiskusikan sudo, mengingat itu hanyalah frontend lain dari dunia CLI? Dengan logika yang sama, Anda dapat mengajukan tiket di repositori ConEmu.

Karena repo itu bukan hanya "aplikasi terminal"; tim yang menjalankannya pada dasarnya memiliki bagian mode teks Windows dan telah mengatakan bahwa mereka tertarik untuk menerapkan sudo ketika mereka dapat menemukan waktu. Di sisi lain, tidak ada orang dari tim PowerShell maupun ConEmu yang menawarkan.

Alasan mengapa menurut saya Windows sudo berada di luar ruang lingkup di sini adalah karena kami telah menentukan bahwa melakukannya dengan benar adalah pekerjaan yang cukup besar dan ortogonal untuk PowerShell itu sendiri. PowerShell dapat menggunakannya jika ada, tetapi ini benar-benar merupakan komponen independen dari shell tertentu.

Di sisi lain, PowerShell yang dapat menjalankan cmdlet melalui biner sudo, terlepas dari platform atau cara kerja biner itu, benar-benar merupakan hal yang harus menjadi bagian dari PowerShell, yang ada di sini.

Saya sebagai pengguna CLI tidak peduli jika sudo adalah sudo linux full blown menggunakan file suders atau beberapa windows. Sudo hanyalah sebuah antarmuka untuk fitur elevasi dari OS. Antarmuka seperti itu dapat dibuat untuk bekerja hampir sama tanpa memandang 'backend'.

Ya, memang seharusnya begitu. Hanya saja sudo belum ada di Windows, akan membutuhkan banyak pekerjaan, dan mungkin tidak akan ditulis oleh tim PowerShell. Ketika hal seperti itu ada, semoga PowerShell mengimplementasikan ini dengan cara di mana itu hanya akan berfungsi di Windows juga.

Bagaimanapun, saya akan menunda komentar lebih lanjut sampai kami mendapatkan tanggapan resmi di sini karena masalah ini mengarah ke berbagai arah.

Ada pendapat tentang ini?
http://blog.lukesampson.com/sudo-for-windows
Dipasang dengan scoop install sudo , itu yang paling dekat yang dapat saya pikirkan. Ia bekerja seperti perintah unix sudo - run dengan elevasi. Saya menggunakannya dengan pip atau Install-Module untuk semua pengguna.

Luke Sampson - Sudo untuk Windows

Sudo untuk Windows

@ Restia666Ashdoll Jika namanya diubah menjadi Invoke-ElevatedCommand Saya baik-baik saja dengan itu.
Itu karena sudo tidak hanya bertanggung jawab untuk meninggikan perintah, tetapi juga untuk meniru pengguna dan hak istimewa "menjatuhkan" ( sudo -u nobody command ). Juga menggunakan kembali nama yang sudah ada terbukti menjadi ide yang buruk, terutama jika fungsionalitas dan parameternya berbeda.
Saya sudah menjelaskan di atas seperti apa sudo sejati dengan peniruan identitas itu dan bagaimana cara kerjanya.

@ Restia666Ashdoll Silakan baca komentar ini di utas ini.

@parkovski Itu hanya pembungkus untuk -Verb RunA, yang hanya bekerja dengan beberapa perintah. Yang saya tautkan dapat digunakan hampir dengan semua hal. Misalnya saya menggunakannya seperti ini - sudo pip install httpie .

Anda tidak membaca posting saya kan?

Saya rasa tidak ada cara untuk mengedit judul untuk menyertakan sesuatu seperti "BUKAN SUDO DI WINDOWS DISCUSSION"? Saya tahu saya secara pribadi tidak berkewajiban untuk terus menjawab ini, tetapi orang-orang terus muncul dengan mengatakan hal yang sama tanpa melakukan penelitian.

Saya mencoba mengklik tautan berhenti berlangganan orang ini dan sayangnya saya tidak mengizinkan saya melakukannya tanpa masuk sebagai dia.

Saya sudah melaporkan @troymoore ke GitHub

Saya ingin mengusulkan solusi unik dan berbeda yang belum pernah saya lihat dibicarakan di sini. Bagaimana dengan menggunakan sesuatu seperti pipa bernama untuk membuat serial perintah ke proses yang ditinggikan yang kemudian mengembalikan keluaran serialnya ke proses pemanggilan?

Berikut adalah modul yang berfungsi yang mendemonstrasikan bagaimana ini akan bekerja pada NT: https://github.com/mmillar-bolis/Invoke-AsAdmin

Ini tidak sempurna, tentu saja, tetapi menyelesaikan tugas dan jalur sederhana yang meningkat tanpa membuka konsol lain. Saya tidak bermaksud untuk mengajukan ini sebagai sudo-alike per se karena saya tidak percaya mengkloning desain sudo akan menjadi solusi jangka panjang terbaik, tetapi saya pikir pendekatan yang berbeda untuk masalah elevasi samar-samar ini mungkin diskusi konstruktif lebih lanjut.

EDIT: Saya juga harus menyebutkan, ini tidak akan memenuhi permintaan @parkovski untuk elevasi UACless.

Sepertinya JEA.
Sedangkan untuk serialisasi, tidak semua modul mendukung ini.

Sepertinya JEA.

Ya, itulah idenya.

Sedangkan untuk serialisasi, tidak semua modul mendukung ini.

Seperti yang mungkin Anda lihat di kode, hal ini dikurangi dengan aliran teks yang merekonstruksi kode di ujung pipa yang lain. Saya akui bahwa ini lambat, tetapi tetap merupakan solusi baru. Anda menyebutkan JEA sekali lagi merupakan faktor yang berpengaruh di sini; jika beberapa bagian dari kode seseorang tidak perlu dinaikkan, seharusnya tidak.

Modul ini dimaksudkan untuk memecahkan masalah yang sangat spesifik dalam mengangkat perintah interaktif dalam sesi GUI di NT dan tidak lebih. Hal ini dimulai seperti lima tahun yang lalu sebelum ada yang membayangkan ssh asli mungkin cocok untuk NT. Saya setuju dengan @parkovski bahwa ini adalah masalah yang terkait dengan cara NT menangani elevasi, jadi tanpa layanan yang mendengarkan dan menyediakan bentuk command elevasi yang berkontur, agak sulit untuk mencapai kasus kemudahan penggunaan yang mirip dengan sudo, pkexec, atau doas.

Namun, alih-alih dihentikan oleh kekeliruan nirwana bahwa implementasi seperti sudo harus ada di NT sebelum PowerShell dapat mendukung segala bentuk elevasi perintah, mengapa kita tidak terlebih dahulu mendorong segala bentuk elevasi interaktif JEA dalam sesi shell?

Ini setidaknya akan mendorong peningkatan praktik keamanan di dunia NT. Mengapa tidak menerapkan cmdlet untuk berjalan secara interaktif, dan satu untuk memulai sesi konsol terpisah? Atau bahkan lebih baik, cukup promosikan cara-cara saat ini untuk memulai sesi yang lebih baik bersama dengan satu set cmdlet yang lebih sederhana dengan kasus penggunaan yang berbeda? Setidaknya itu satu langkah maju.

Saya juga dapat menambahkan bahwa pustaka elevate Python tidak dapat melakukan apa yang dilakukan modul ini. Apakah Anda sudah menemukan modul lain yang belum berfungsi? Karena poin utama saya adalah mungkin pikiran yang lebih pintar dari saya dapat mengambil modul ini dan ide-idenya dan menjalankannya ke arah yang sesuai untuk NT. Setelah itu, kita mungkin memiliki permulaan platform untuk NT dan * nix bertemu di tengah, memungkinkan kita merevisi implementasi yang lebih umum untuk PowerShell untuk meningkatkan perintah.

Itu setidaknya dua sen saya. Tetapi setelah melihat kodenya, jika seseorang merasa bahwa ide-ide di dalamnya tidak baik, saya akan mengerti. Aku belum pernah melihat siapa pun yang mencoba sesuatu seperti ini.

Akan mundur dari kesedihan saya yang membuat frustrasi menjelaskan poin sudo sebentar karena (a) ya ini adalah masalah yang sangat sulit, (b) benar-benar hanya dapat diselesaikan dengan baik oleh MS (terima kasih karena tidak menjadi open source, Windows), (c) sungguh menyenangkan melihat bahwa orang lain juga menyukai hal ini.

Saya tahu betapa sulitnya melakukan ini dengan benar karena saya mulai menyusuri jalan itu. Jadi jika satu-satunya hal yang menghalangi kita untuk saat ini adalah dialog UAC, biarlah. Setidaknya dengan cara ini kita dapat menguji solusi lintas platform dengan sedikit usaha.

Apa yang secara pribadi ingin saya lihat dari PowerShell adalah dukungan komprehensif untuk sudo Unix, tetapi dirancang untuk mendukung beberapa bentuk skrip "pseudo-sudo" seperti sekarang serta potensi masa depan Windows sudo. Pemikiran saya adalah bahwa jika seseorang membuat prototipe bagaimana sudo Windows pada akhirnya akan bekerja tetapi meninggalkan batasan UAC, itu seharusnya cukup mudah, memberi kami sesuatu yang pada dasarnya sebagus yang didapat untuk saat ini, dan ketika kami mendapatkan hal yang nyata itu seharusnya cukup banyak hanya menjadi pengganti drop-in.

Jelas ini berarti seseorang harus datang dengan model yang memahami atau setidaknya diterjemahkan ke model uid / gid Unix dan model sid / acl Windows. Semoga orang ini menyukai tantangan. Menebak ini juga akan membutuhkan beberapa pembicaraan dengan terminal dan tim keamanan windows dalam MS.

Saya rasa dengan banyaknya orang yang telah menciptakan solusi dengan upaya terbaik mereka sendiri, dan mendukung sesuatu seperti ini dapat membantu merancang cara yang kuat untuk melakukan ini, mengapa tidak?

Sidenote - siapa pun yang menulis skrip solusi ini mungkin menganggap fitur batas waktu yang dimiliki sudo, sama menyebalkannya dengan popup itu.

Kita bisa memikirkan tentang Start-Process pwsh -NoNewWindow -Credential $cred . Ini tidak berhasil tapi bisa.

Jelas ini berarti seseorang harus datang dengan model yang memahami atau setidaknya diterjemahkan ke model uid / gid Unix dan model sid / acl Windows. Semoga orang ini menyukai tantangan. Menebak ini juga akan membutuhkan beberapa pembicaraan dengan terminal dan tim keamanan windows dalam MS.

Unix juga memiliki acls dan windows memiliki kompatibilitas posix dan setidaknya jika domain joint juga ada atribut grup utama yang bisa kita gunakan (serta atribut posix). Ini hanya perlu diimplementasikan untuk klien windows yang bukan domain join (atau untuk saat ini diasumsikan User ).

Model generik untuk izin unix dan windows pada dasarnya adalah:
ACL dengan Pengguna Pemilik dan Grup Pemilik dengan beberapa ACE yang diharapkan (pengguna, grup, dan lainnya).

Daripada kita bisa memetakan izin unix sebagai:
uid => SID Pemilik
gid => SID grup utama dari pengguna yang membuat objek.
pengguna => ID Pemilik Pembuat S-1-3-0
grup => ID Grup Pembuat S-1-3-1
lainnya => Dunia / Semua Orang S-1-1-0
Memetakan uids dari daftar acl di unix sedikit lebih rumit karena kami perlu mempertimbangkan bahwa sistem mungkin merupakan bagian dari ldap, direktori aktif, atau direktori lainnya. Dua kasus yang akan saya pertimbangkan dalam lingkup PowerShell adalah tidak ada direktori dan direktori ldap / aktif.
Dalam kasus pertama saya sarankan menggunakan S-1-6-1-uid dan S-1-6-2-gid (dengan asumsi S-1-6 masih tersedia dan tim yang bertanggung jawab bersedia mengalokasikannya untuk tujuan ini ).
Dan untuk kasus kedua kita hanya perlu memiliki semacam penyelesaian uid melalui backend otentikasi. Server direktori ldap / aktif bertanggung jawab untuk menyediakan sid.
Dan terakhir ada beberapa kasus khusus untuk dipetakan:
uid 0 => S-1-5-32-544
gid 0 => S-1-6-500 (dan S-1-5-21 - * - 500)
sebagian besar sids terkenal lainnya dapat dikelola melalui file konfigurasi atau melalui semacam api (atau lepaskan saja karena kemungkinan besar tidak akan digunakan)

Jika kita melakukan ini di shell, buat perintah seperti Get-Acl / Set-Acl daripada mulai bekerja pada sistem unix tanpa mengetahui tentang bagaimana izin disimpan pada disk.

@ mmillar-bolis Saya sudah menyarankan pendekatan menggunakan soket di sini: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

Kita bisa memikirkan tentang Mulai-Proses pwsh -NoNewWindow -Credential $ cred. Ini tidak berhasil tapi bisa.

Pembaruan: .Net Core (dan saya kira Windows API juga) tidak memungkinkan untuk menjalankan proses baru yang terpasang ke konsol yang sama.

Jadi satu-satunya cara yang dapat kita gunakan adalah Layanan Windows yang ditinggikan. Tetapi kita harus membuat proses layanan seperti itu per "sudo" agar aman.
Jadi solusinya adalah New-PSSession (atau dipanggil di PSSession) ke localhost dengan kredensial pengguna yang ditingkatkan.

@iSazonov Satu-satunya hal yang memungkinkan Anda untuk memasangnya ke konsol yang sama adalah apa yang telah saya sebutkan di sini: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

Sekarang setelah windows mendukung soket unix, kita dapat menggunakan salah satunya atau bernama pipa dan layanan istimewa akan bertanggung jawab untuk memvalidasi kredensial dan perlu dijalankan sepanjang waktu (dibandingkan dengan dipanggil melalui suid seperti yang disebutkan dalam posting terkait untuk * nix oses) .

Mungkin lsas akan / perlu diperpanjang untuk menyediakan kemampuan api otentikasi seperti itu?
Dengan begitu, kami bisa mendapatkan peniruan identitas penuh sambil tetap dapat memasang dengan aman ke konsol yang sama dan menerima masukan.

@ agowa338 Proposal Anda "de-facto" adalah PowerShell dari jarak jauh. Ini sudah diterapkan.

Tapi

Jadi solusinya adalah New-PSSession (atau dipanggil di PSSession) ke localhost dengan kredensial pengguna yang ditingkatkan.

tidak berfungsi untuk localhost. Itu hanya melempar AccessDenied.

Kecuali salah satu kasusnya:

• UAC tidak aktif
• Anda mencoba untuk menyambung ke BUILDIN \ Administrator tanpa Mode Persetujuan Admin diaktifkan.
• proses (PowerShell) sudah meningkat.

Berikut adalah penjelasan yang bagus mengapa oleh @ jborean93 : https://github.com/PowerShell/Win32-OpenSSH/issues/1308#issuecomment -448430464

Oleh karena itu kami memerlukan layanan istimewa yang bertindak sebagai perantara atau salah satu API perlu diubah, tetapi itu bukan sesuatu yang dapat kami lakukan di dalam PowerShell / PowerShell dan perlu didelegasikan oleh orang-orang Microsoft secara internal.

@ agowa338 Komentar yang Anda rujuk adalah tentang API Windows lokal, bukan PowerShell remoting yang merupakan pertanyaan di sana.

@iSazonov : Apakah Anda pernah mencoba melakukan PowerShell remote ke localhost? Saya melakukannya dan tidak berhasil karena alasan yang diuraikan di atas. Penetapan accesstoken diblokir oleh os.

PowerShell remoting ke localhost tidak memungkinkan untuk mendapatkan hak istimewa yang lebih tinggi di komputer lokal.

Namun PowerShell remoting memberi Anda hak istimewa yang lebih tinggi pada semua host lain di jaringan kecuali localhost (dengan asumsi Anda adalah anggota Domain-Admins, dll).

Itulah alasan mengapa kami membutuhkan sudo yang setara di windows. Jika PowerShell remoting berperilaku seperti itu menurut Anda tiket ini dapat ditutup dengan menulis contoh ke dalam dokumen karena fungsinya sudah ada.

@ agowa338 Ini tidak bekerja untuk Anda karena perlindungan keamanan. Ini bukan fitur OS. Anda dapat mengkonfigurasi WinRM seperti yang dijelaskan di docs https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting . Masalah yang Anda rujuk juga mengatakan bahwa ini berfungsi untuk SSH (langkah-langkahnya dirujuk di artikel itu).

karena fungsinya sudah ada.

Permintaan adalah untuk mulai bekerja "sudo Remove-Item foo.txt dimana foo.txt dimiliki oleh root".
Ini tidak berhasil tetapi kami ingin.
Masalahnya terdiri dari dua bagian: gula sintaks dalam bahasa dan implementasi.

Jika Anda berpikir lebih banyak tentang proposal Anda, Anda menemukan bahwa Anda perlu memiliki konteks per pengguna / per sesi / per runspace / per lingkup PowerShell. Kemudian Anda harus memenuhi persyaratan kepatuhan keamanan dan Anda akan mendapatkan "akses ditolak" dalam konfigurasi default. Setelah itu, proposal Anda akan sama seperti yang sudah diimplementasikan PowerShell remoting.

about_Remote_Troubleshooting - PowerShell

Ini tidak bekerja untuk Anda karena perlindungan keamanan. Ini bukan fitur OS. Anda dapat mengkonfigurasi WinRM seperti yang dijelaskan di dokumen

@iSazonov Bisakah Anda menjelaskannya lebih lanjut? Saya dapat melakukan remote ke mesin itu dan dari mesin manapun ke mesin lain di jaringan, tetapi dari tidak satupun ke localhost. Dan ya saya membaca halaman itu.

Permintaan adalah untuk mulai bekerja "sudo Remove-Item foo.txt dimana foo.txt dimiliki oleh root".

Untuk sistem non-windows kita dapat menggunakan pendekatan soket unix untuk mengimplementasikan peniruan / elevasi untuk PowerShell remoting di sana.

Bisakah Anda menjelaskannya lebih lanjut? Saya dapat melakukan remote ke mesin itu dan dari mesin manapun ke mesin lain di jaringan, tetapi dari tidak satupun ke localhost. Dan ya saya membaca halaman itu.

Sebagian besar serangan menargetkan ketinggian lokal. Jadi semua konfigurasi "diamankan secara default". WMI, WinRM, IIS loopback dan lain-lain - semua subsistem menonaktifkan fitur yang memungkinkan elevasi lokal.
Tidak begitu penting untuk diskusi. Bahkan jika PowerShell remoting tidak memungkinkan kami melakukan sudo secara default, kami dapat menerapkannya dimatikan secara default atau hanya mengizinkan untuk sesi interaktif.

Anda mulai berbicara tentang windows, untuk sistem non windows kita bisa menggunakan pendekatan soket unix untuk mengimplementasikan peniruan / elevasi untuk PowerShell remot di sana.

Kami harus memiliki UX yang sama untuk semua platform. Benar-benar ada PSRP bekerja melalui transportasi - WinRM atau SSH. MSFT mengatakan bahwa mereka menyukai SSH tetapi saya tidak melihat kemajuan yang berarti selama dua tahun terakhir. Dan sulit dipercaya bahwa mereka akan menginginkan protokol ketiga di masa depan _dekat_ - terlalu banyak pekerjaan (kebutuhan untuk menjaga kompatibilitas dengan sistem lama).

Sebagian besar serangan menargetkan ketinggian lokal. Jadi semua konfigurasi "diamankan secara default". WMI, WinRM, IIS loopback dan lain-lain - semua subsistem menonaktifkan fitur yang memungkinkan elevasi lokal.
Tidak begitu penting untuk diskusi. Bahkan jika PowerShell remoting tidak memungkinkan kami melakukan sudo secara default, kami dapat menerapkannya dimatikan secara default atau hanya mengizinkan untuk sesi interaktif.

Saya mencoba untuk mengaktifkannya beberapa waktu yang lalu, dan saya diberitahu berulang kali oleh banyak orang lain bahwa ini dibatasi oleh os secara internal dan tidak mungkin dengan cara apapun tanpa aplikasi yang menghubungkan jauh ke internal windows. Faktanya banyak yang menunjuk pada batasan api windows yang direferensikan di atas dan menggunakannya sebagai argumen mengapa PowerShell tidak pernah bisa menyediakan kemampuan seperti itu. Dan seseorang bahkan mereferensikan CVE di mana elevasi loopback sengaja dihapus. Oleh karena itu, maaf jika Anda melihat lubang kelinci itu lebih dalam, tetapi apa yang harus saya konfigurasikan agar berfungsi? Apakah itu didokumentasikan di mana saja?

Kami harus memiliki UX yang sama untuk semua platform. Benar-benar ada PSRP bekerja melalui transportasi - WinRM atau SSH. MSFT mengatakan bahwa mereka menyukai SSH tetapi saya tidak melihat kemajuan yang berarti selama dua tahun terakhir. Dan sulit dipercaya bahwa mereka akan menginginkan protokol ketiga dalam waktu dekat - terlalu banyak pekerjaan (kebutuhan untuk menjaga kompatibilitas dengan sistem lama).

Sebaiknya kita mendorong salah satu dari kedua solusi karena keduanya bekerja pada platform apa pun.

• PSRP: SSH ke localhost berfungsi untuk elevasi di Windows dan Linux, oleh karena itu menggunakan subsistem psrp kita sudah memiliki izin yang benar, jadi hanya lapisan PowerShell yang harus diseragamkan untuk memungkinkan lewatnya objek. Baik?
• Menggunakan soket unix juga akan menyediakan fungsionalitas serupa seperti PowerShell remoting, tetapi saat penulisan, saya berasumsi bahwa melakukan elevasi lokal tanpa jenis layanan tambahan apa pun yang berjalan sebagai sistem lokal untuk melakukan pertukaran token ...

Oleh karena itu, karena PowerShell Remoting sudah ada (dan juga sudah bekerja di atas ssh) kita harus memprioritaskan solusi itu menurut saya.

Dan seseorang bahkan mereferensikan CVE di mana elevasi loopback sengaja dihapus.

Saya tidak bisa memastikan. Saya kira CVE hanya bisa menonaktifkan loopback secara default tetapi tidak sama sekali.
Lihat juga https://github.com/PowerShell/PowerShell/issues/3874#issuecomment -510715727

@iSazonov : Itu tidak berhasil, ini hanya menyediakan token akses hak istimewa rendah tetapi bukan token akses yang ditinggikan (misalnya Mandatory Label\High Mandatory Level ). Saya tidak mendapatkan izin Administratif dari PowerShell hak istimewa rendah meskipun TrustedHosts disetel ke * untuk saya. Token logon selalu berjenis interaktif, bahkan setelah Enter-PSSession.
Saya sebenarnya dapat Enter-PSSession localhost -ScriptBlock {} tetapi kredensial yang lewat menyebabkan "Access Denied". , tidak selalu muncul "Access Denied" bahwa sistem lain telah menonaktifkan UAC.

Tapi sekarang saya mencobanya juga menggunakan SSH dan itu berfungsi seperti yang diharapkan itu menyediakan token yang ditinggikan ( Mandatory Label\High Mandatory Level ) dengan jenis logon Jaringan.

Oleh karena itu di PSCore kita dapat mengandalkan psrp untuk elevasi (bahkan secara lokal melalui Enter-PSSession -HostName localhost yang juga berfungsi dengan kredensial eksplisit yang diteruskan.
Dimana Enter-PSSession -ComputerName localhost -Credential $foo tidak (meskipun $ foo.Nama pengguna sama dengan pengguna saat ini)

@ agowa338 Saya rasa kita tidak boleh membahas melewati fitur keamanan WinRM di sini (ini adalah area kepatuhan yang sensitif). Saya hanya dapat menunjukkan (1) bahwa terlepas dari protokolnya, keamanan harus tetap pada tingkat yang sama, yang menyiratkan bahwa loopback SSH harus berperilaku sama seperti untuk WinRM dengan mempertimbangkan cara kerja internal Windows, (2) implementasi sudo PS harus berfungsi transportasi apapun.

@iSazonov : Saya tidak meminta exploit, tetapi hanya untuk apa yang perlu dikonfigurasi untuk mengaktifkannya. Anda juga menjadi satu-satunya yang menemukan cara mengkonfigurasi WinRM untuk memungkinkan elevasi loopback.
Saya sudah mencoba mengaktifkannya untuk waktu yang sangat lama. Semua pertanyaan (tentang stackoverflow, reddit, masalah github, ...) yang saya temukan diakhiri dengan "windows is wird", "tidak tahu apa yang dilakukan windows di sana", "Tidak didokumentasikan di mana pun", "Windows tidak menyediakan kemampuan itu "," Gunakan Linux sebagai gantinya "," Nonaktifkan UAC "," Anda perlu menulis layanan broker yang berjalan dengan hak istimewa sistem ". Jadi tolong jika Anda sudah menemukannya, bagikan pengetahuan Anda.

Saya hanya dapat menunjukkan (1) bahwa terlepas dari protokolnya, keamanan harus tetap pada level yang sama

Apa maksudmu dengan itu?

yang menyiratkan bahwa loopback SSH harus berperilaku sama seperti untuk WinRM dengan mempertimbangkan cara kerja internal Windows

SSH memiliki layanan sistem yang bertindak sebagai pialang di latar belakang untuk melakukan hal itu. Ini menyediakan token akses Jaringan ...

(2) Implementasi PS sudo harus bekerja pada semua transportasi.

Yah itu tidak lebih dari WinRM karena alasan itu. Jadi jika benar apa yang Anda katakan, kami memerlukan dokumentasi tentang cara mengaktifkan loopback WinRM.

jika Anda berhasil menemukannya, bagikan pengetahuan Anda.

Tim MSFT @ agowa338 meminta saya untuk tidak membahas keamanan secara publik dan saya mengikuti CoC. Saya mendukung keinginan Anda untuk menjelajahi topik ini secara mendalam, tetapi sebagai bagian dari diskusi ini, ini memusingkan bagi MSFT untuk mengintegrasikan solusi ini ke dalam Windows dan menjaga kepatuhan keamanan.

Nah itu tidak membantu siapa pun.

Untuk memanggilnya:

• Anda mengatakan windows memiliki kemampuan sudo seperti di dalam WinRM.
• Itu tidak didokumentasikan bahwa itu ada atau bagaimana mengaktifkan / menonaktifkannya.
• Mengungkapkan cara menggunakannya akan menjadi risiko keamanan.

Maaf, tapi itu terdengar seperti pintu belakang dan bukan fitur. Ini tidak dapat digunakan untuk siapa pun kecuali Anda daripada.
Juga keamanan melalui ketidakjelasan juga tidak berfungsi di masa lalu ...

Jadi kami kembali pada saat ini belum diterapkan dan kami membutuhkan layanan broker daripada ...

@ agowa338 Kami telah mengumpulkan cukup informasi untuk disimpulkan oleh tim MSFT. Jika mereka menemukan masalah keamanan, mereka akan menunjukkan kepada kami cara alternatif yang dapat diterima.

Itu mungkin tetapi telah ditambal awal tahun ini https://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/ dengan patch KB4480116 dan pembaruan kumulatif berikutnya .. Sebelum pembaruan ini, dimungkinkan untuk meningkatkan hak istimewa Anda jika Anda memiliki LocalAccountTokenFilterPolicy yang disetel ke 1 yang mana winrm quickconfig tidak (dan diperlukan untuk WinRM sebenarnya).

Ada catatan di sana yang mengatakan bahwa titik akhir JEA tidak terpengaruh sehingga Anda berpotensi dapat membuat PSSessionConfiguration Anda sendiri dan terhubung ke sana, tetapi saya belum menguji ini untuk memverifikasi. Secara pribadi saya pikir tambalan ini konyol karena tambalan ini hanya menghentikan klien PowerShell agar tidak terhubung ke localhost tetapi Anda dapat dengan mudah mem-bypassnya jika Anda tahu apa yang Anda lakukan. Misalnya saya masih bisa beralih dari terbatas ke ditinggikan tanpa menyentuh UAC dengan menggunakan SSH atau klien PSRemoting lain seperti itu

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

Kita dapat melihat bahwa menggunakan SSH kita memiliki token yang ditinggikan, kita juga dapat melihat bahwa menggunakan pustaka pihak ke-3 kita masih dapat menggunakan localhost PSRemoting yang membuat token yang ditinggikan dan bahwa tambalan bukanlah blok total dari fungsionalitas ini.

Saya tidak melihat ini sebagai masalah keamanan atau melewati batas keamanan karena MS telah berulang kali mengatakan bahwa UAC bukanlah batas keamanan

• 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/

Ini mungkin dekat atau bertindak mirip dengan yang satu tetapi tidak selalu mudah. Salah satu cara untuk melewati UAC adalah properti registri LocalAccountTokenFilterPolicy yang diketahui dan didokumentasikan. Tujuan eksplisit dari properti ini untuk memastikan bahwa logon jaringan selalu dinaikkan dan bukan token yang difilter dan secara eksplisit disebutkan bahwa tidak mengaktifkannya akan mencegah serangan "loopback"

Untuk lebih melindungi pengguna yang merupakan anggota grup Administrator lokal, kami menerapkan pembatasan UAC di jaringan. Mekanisme ini membantu mencegah serangan "loopback". Mekanisme ini juga membantu mencegah perangkat lunak berbahaya lokal berjalan dari jarak jauh dengan hak administratif.

Pada akhirnya, maksudnya adalah tidak ada cara yang benar-benar resmi di Windows untuk meningkatkan hak istimewa Anda dari terbatas menjadi admin dengan cara non-interaktif. Sangat mudah untuk menggunakan Start-Process ... -Verb Runas tetapi itu membutuhkan logon interaktif untuk menampilkan prompt UAC. Memiliki mekanisme seperti sudo akan membantu meringankan masalah ini tetapi untuk melakukannya dengan benar akan membutuhkan pekerjaan di Windows itu sendiri dan bukan khusus PowerShell. Ada "solusi" tetapi saya tidak akan menyebutnya resmi dan hanya produk sampingan yang diketahui dari mengaktifkan WinRM.

PowerShell

Perubahan Keamanan Windows memengaruhi PowerShell |

Perubahan Keamanan Windows memengaruhi PowerShell 9 Januari 2019 Patch keamanan Windows CVE-2019-0543 (1/8/2019) terbaru, telah memperkenalkan perubahan yang merusak untuk skenario jarak jauh PowerShell. Ini adalah skenario dengan cakupan sempit yang seharusnya berdampak rendah bagi sebagian besar pengguna. Perubahan yang melanggar hanya mempengaruhi remote loopback lokal,

Mark's Blog

PsExec, Kontrol Akun Pengguna dan Batas Keamanan

Saya memperkenalkan -l switch ke PsExec sekitar satu setengah tahun yang lalu sebagai cara mudah untuk menjalankan proses dengan hak pengguna standar dari akun administratif di Windows XP. Dalam Menjalankan sebagai Pengguna Terbatas - Cara Mudah, saya menjelaskan bagaimana PsExec menggunakan API CreateRestrictedToken untuk membuat konteks keamanan yang ...

Rekayasa Windows 7

Pembaruan di UAC

Hai, Jon DeVaan di sini untuk berbicara dengan Anda tentang umpan balik UAC baru-baru ini yang kami terima. Sebagian besar pekerjaan kami yang menyelesaikan Windows 7 difokuskan pada menanggapi umpan balik. Umpan balik UAC menarik pada beberapa dimensi proses pengambilan keputusan teknik. Saya pikir menjelajahi dimensi itu akan membuat e7 menarik ...

@iSazonov Tak satu pun dari saran ini yang akan mencapai elevasi perintah _user-interactive_ dari _dalam sesi konsol yang sama_, terutama di lingkungan yang _lacks UAC_. Tampaknya Anda dapat berbicara atas nama Microsoft dalam masalah ini, jadi maukah Anda menjelaskan apakah mereka tidak tertarik untuk memperkenalkan fitur seperti yang telah saya jelaskan?

Jika itu terjadi, seperti yang telah saya ditafsirkan dari posting di atas, tampaknya bijaksana untuk menutup thread ini, sebagai sisa dari kita pengguna harus mencari tempat lain untuk solusi seperti @parkovski 's TokenServer ide.

Tampaknya Anda dapat berbicara atas nama Microsoft dalam masalah ini

Saya adalah pengelola komunitas proyek, bukan anggota MSFT dan saya tidak dapat berbicara atas nama Microsoft.

apakah Anda akan menjelaskan apakah mereka tidak tertarik untuk memperkenalkan fitur seperti yang saya jelaskan?

_Semua proposal memiliki nilai; tidak satupun dari mereka ditolak. Diskusi hanya untuk mengumpulkan semua proposal yang memungkinkan._

Saat ini saya mencoba merangkum semua proposal agar kita bisa maju dan tidak stagnan.

Itu yang saya lihat.
Skenario utama adalah adopsi pengguna Unix di Windows.

• Secara historis, pengguna Unix bekerja di satu konsol dan sudo secara native membantu mereka melakukan pekerjaan dengan hak yang lebih tinggi di konsol _same_
• Secara historis, pengguna Windows membuka jendela baru dengan konsol hak yang ditinggikan jika diperlukan. Ini bekerja dengan baik selama bertahun-tahun karena nyaman dalam lingkungan multi-jendela. (Pengguna Windows bisa mendapatkan keuntungan dari pssudo juga dengan mempertimbangkan Windows Core dan Nano)

Jadi harapannya adalah:

• pssudo hanya berfungsi dalam sesi interaktif
• pssudo tidak membuka konsol baru (jendela UAC dapat diterima di Windows, kami tidak ingin merusak keamanan dan semangat Windows)
• pssudo kredensial cache tepat waktu
• pssudo tidak menyimpan status sesi untuk keamanan
• UX yang sama (mungkin) ada di semua platform
• pssudo menjalankan perintah asli
• pssudo menjalankan blok / file skrip PowerShell

Detail implementasi:

• PowerShell remoting adalah solusi paling kuat dan fungsional. Ini sudah diterapkan dan berfungsi. Orang lain harus meniru fungsionalitas ini juga untuk mengeksekusi blok skrip PowerShell di per pengguna / per sesi / per runspace / per status cakupan.
• Transportasi yang disukai adalah WinRM karena semua infrastruktur Windows didasarkan padanya. Beberapa investasi diperlukan di WinRM, meskipun MSFT tidak menginginkannya karena ini didasarkan pada SOAP.
• Bisa jadi transportasi SSH. Ini masih bukan standar untuk Windows. Membutuhkan investasi yang besar untuk implementasi dan pemeliharaan. Dan ada masalah yang mendukung sistem lama.
• Transportasi lain seperti soket Unix. Membutuhkan investasi yang besar tidak hanya dalam infrastruktur tetapi juga di PowerShell.

@ mklement0 Saya ingin tahu yang saya lakukan di sini yang biasanya Anda lakukan dengan baik :-) Anda merampok saya sebagai lawan :-)

Mengapa tidak menulis biner windows yang membutuhkan hak istimewa yang memulai instance PowerShell dengan perintah apa pun yang diteruskan padanya. Ini harus menjadi aplikasi mode konsol agar berfungsi dengan baik. Kemudian untuk linux, kami menulis skrip yang memerlukan izin yang memulai instance PowerShell dengan perintah yang disediakan. Jika ini berfungsi dalam praktik seperti dalam teori, PowerShell akan diluncurkan dengan izin yang ditinggikan, menjalankan perintah, dan keluar.

Mengapa tidak menulis biner windows yang membutuhkan hak istimewa yang memulai instance PowerShell dengan perintah apa pun yang diteruskan padanya. Ini harus menjadi aplikasi mode konsol agar berfungsi dengan baik.

Penyebab windows API mencegahnya dan aplikasi konsol akan terbuka di jendela baru. Kami sudah berbicara tentang kemungkinan solusi.

Satu hal yang perlu diingat adalah bahwa tidak peduli bagaimana ini diimplementasikan, selalu ada proses melompat ke dan dari proses yang lebih tinggi. Ini berarti Anda akan selalu memiliki objek deserialisasi di pipeline dan batasan tersebut akan berlaku. Dalam banyak kasus, ini tidak akan menjadi masalah, tetapi jika cmdlet mengharapkan objek .NET langsung, maka itu tidak akan berfungsi.

Untuk mendukung JEA dengan SSH, pada akhirnya kita memerlukan daemon / layanan umum yang menggantikan kebutuhan WinRM sebagai layanan itu. Pada saat itu, kami akan mengevaluasi penggunaan itu untuk meninggikan sebagian pipa.

FYI: https://github.com/gerardog/gsudo

GitHub

gerardog / gsudo

Sudo untuk Windows - berjalan tinggi tanpa menjangkau Jendela Host Konsol baru - gerardog / gsudo

FYI: https://github.com/gerardog/gsudo

GitHub gerardog / gsudo A Sudo untuk Windows - berjalan tinggi tanpa menjangkau Jendela Host Konsol baru - gerardog / gsudo

Bahkan lebih baik
http://blog.lukesampson.com/sudo-for-windows

GitHub

gerardog / gsudo

Sudo untuk Windows - berjalan tinggi tanpa menjangkau Jendela Host Konsol baru - gerardog / gsudo

Luke Sampson - Sudo untuk Windows

Sudo untuk Windows

Bahkan lebih baik

Tidak.

Gsudo tidak meminta kata sandi setiap kali dan diketahui lebih cepat untuk diinstal dan digunakan.

Menurut saya masalah ini harus diterima (yang berarti lebih banyak waktu dan organisasi harus diberikan untuk itu) dilihat dari minat tidak hanya dari tiket ini. Tidaklah benar untuk tidak secara resmi mengakuinya sebagai tugas kerja karena kesulitan teknis yang saat ini dirasakan tidak akan diselesaikan tanpa keterlibatan aktif.

Saya menggunakan gsudo selama beberapa bulan sekarang dan saya tidak dapat membayangkan kembali ke Windows UAC tradisional sepanjang waktu.

@majkinetor masalah ini dipisahkan di https://github.com/PowerShell/PowerShell/issues/11343 untuk diskusi lebih lanjut tentang desain