Powershell: دعم sudo<powershell cmdlet=""/>

همهمة! مثير جدا. لكني أعتقد أن السلوك الفعلي كما هو متوقع. كما هو الحال في Windows ، ليس لدينا أمر مثل sudo.
ولكن ، يمكنك استخدام sudoowershell ثم القيام بإزالة foo.txt (الذي تم إنشاؤه باستخدام sudoowershell) ثم يعمل عند استخدام Remove-Item. بالطبع ، لن يعمل بإذن غير مرتفع.

سأستخدم فقط sudo في أوامر Linux ("sudo nautilus") من داخل PowerShell.

:)

حتى في نظام التشغيل Windows ، سيكون من الجيد أن يكون لديك قدرة مماثلة لتشغيل cmdlet مثل مستخدم آخر أو مستخدم آخر أو شيء يمكن الاعتماد عليه في البرامج النصية المحمولة. قد تحتاج إلى RFC لهذا الغرض.

قد تكون هذه الوظيفة مفيدة للتغلب على # 3506.

سيصبح هذا مانعًا لتكييف Linux بالنسبة لي إذا لم يتم حل ذلك. لا يُسمح لنا باستخدام sudo bash وبالمثل لن نكون قادرين على عمل sudoowershell.

أتفق مع Maximo ، يجب أن نترك sudo لباش ونصنع أمر cmdlet جديدًا للقيام بالارتفاع في powerhell باستخدام sudo كسقالات على الوظائف المتوقعة.

dantraMSFT كان يحقق في هذا الأمر ، هل يمكنك دان أن تقدم تحديثًا لبعض الأفكار الحالية حول هذا الأمر؟

pixelrebirth هل يمكنك تقديم المزيد من التفاصيل حول ما تتوقعه؟ هل تتوقع تنفيذًا بسيطًا مع انتظار أو إعادة توجيه الإخراج أو إعادة توجيه خط الأنابيب؟
بعض الأمثلة على الاستخدام قد تكون مفيدة أيضًا.

dantraMSFT من أجل الجدل سأقوم باستدعاء sudo الجديد مثل cmdlet: Invoke-Elevated
هذه هي الطريقة التي يعمل بها sudo وسيترجم إلى Invoke-Elevated بطريقة بوويرشيل

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

في هذا المثال ، سيتم تنفيذ كل شيء في scriptblock مرتفعًا ثم توجيهه إلى ملف Get-SomeCmdlet غير مرتفع
يمكن أن يكون Cred مستخدمًا مختلفًا أو أنت نفسك كمستخدم مرتفع (يجب الاحتفاظ بالأذونات في مكان ما مثل ملف sudoers المعروف أيضًا باسم القائمة البيضاء)

يجب تمكين التسجيل افتراضيًا للحالات التي يتم فيها تنفيذ Invoke-Elevated:
المستخدم | أمر | DateTime أو تنسيق مماثل

ربما يتم تمديد بعض هذا أو تغييره لاحقًا ، ولكن هذا ما قد يزيل أدوات الحظر الخاصة بي

يجب أن تعمل أيضًا مثل:

Get-ChildItem ./test | Invoke-Elevated -command {Remove-Item -force}
حيث تكون بيانات الاعتماد هي المستخدم الحالي وتطلب فقط كلمة المرور ...

Get-ChildItem غير مرتفع ، تمت إزالة العنصر في هذا المثال

كنت في مكالمة المجتمع اليوم أسأل عن هذا الأمر ، لكن زوجتي أصيبت أثناء شرح التحديات التي واجهتها وفقدت الكثير منها. هل يمكنك تدوين الملاحظات هنا من فضلك حتى أتمكن من نقلها إلى رئيسي؟

سأساعد مهما كان ذلك ممكنا وأمارس الضغط أينما احتاج إلى ذلك.

pixelrebirth أتمنى أن تكون بخير! سنقوم بتسجيل المكالمة في اليوم أو اليومين التاليين ، حتى تتمكن من اللحاق بها إذا أردت.

الملخص الأساسي هو أن dantraMSFT يجري تحقيقًا أوليًا لمعرفة كيفية القيام بذلك بطريقة غير متطرفة. اليوم ، يمكنك sudo powershell -c "invoke-foo" من قشرة أخرى ، لكن من الواضح أن هذا غير عملي.

dantraMSFT : أثناء عملك في التحقيق ، ربما تنشر بعض الحالة للتأكد من أن الجميع يفهم المفاضلات بأساليب مختلفة؟

قد يبدو الأمر واضحًا ، لكن ربما يمكنك إلقاء نظرة على كود مصدر sudo ومعرفة كيفية إدارته - ربما يتطلب بعض الترميز منخفض المستوى. أتمنى لو كان لدي فهم أعمق للكود للمساعدة.

إنها بخير ، إنها تشعر على وركها الجراحي. شكرا على الرد السريع على هذا. أنا أعمل على حل بسيط للاختراق وسأنشر هنا إذا سحبت ذلك.

pixelrebirth كمرجع ، يستخدم sudo بت setuid ، راجع https://unix.stackexchange.com/a/80350/86669 للحصول على التفاصيل. من المحتمل أن يكون وضع ذلك على غلاف كامل فكرة سيئة.

يجب أن يتوفر لديك sudo الأصلي (لذلك ربما لا تنتمي المشكلة هنا ، على الرغم من أن الخيار الذي يمكن استخدامه فقط عبر Powershell مقبول بالنسبة لي). لقد استخدمت Powershell منذ البداية وشاهدت 99 نوعًا مختلفًا من برنامج sudo النصي ، مثل Invoke-Elevated أعلاه (أو بلدي الذي أستخدمه كل يوم). تضمين cmdlet مثل ذلك في Powershell سيكون خطوة للأمام ، ومع ذلك ، فإنهم جميعًا يشعرون بأنهم مرهقون بالنسبة لكيفية عمل ذلك على Linux.

أحد الأشياء المزعجة بالنسبة لي هو أنه يبدأ نافذة غلاف جديدة (وليس على نظام التشغيل Linux) والتي أود أن أراها مطبقة في Powershell / Windows ، لست متأكدًا مما إذا كان هذا ممكنًا تقنيًا على Windows tho.

على الرغم من أنني أحب فكرة أمر cmdlet آخر ("Invoke-Elevated") والذي يمكن استخدامه في Windows ، إلا أنني لا أفهم لماذا لا تلتزم بفتح PowerShell باستخدام "sudo" إذا كنت بحاجة إلى إنشاء نص برمجي لتشغيله مع شرف؟

خاصة إذا كنت تقوم بأتمتة مهمة ستتم جدولتها في النهاية للتشغيل بنوع من بيانات اعتماد الامتياز العالية على أي حال.
:)

لأن هذا ليس سير العمل النموذجي. أنت لا "sudo" وتعيش هناك إلى الأبد ، فأنت تريد أوامر محددة وتعيش في عالم غير sudo. لا توجد طريقة سريعة للقيام بذلك في Windows ، كما أن بوويرشيل نفسه بطيء جدًا في البدء ، خاصةً مع تضمين القليل من عناصر الملف الشخصي.

في جلسة عادية كل يوم ، سأقوم بأوامر محددة 20 مرة ، وأخرى تعمل بدون امتيازات. هذا هو بيت القصيد من sudo ، رفع الامتياز فقط عند الضرورة وقد يكون ضروريًا في كثير من الأحيان.

كان سير العمل الخاص بي ، أمر التشغيل ، يشكو من الامتياز ، أنا sudo -L الذي سيقوم بتنفيذ الأمر الأخير مرة أخرى بامتياز. نظرًا لأن الفخامة بطيئة جدًا في البداية ، فأنا أقوم فقط بتشغيل shell admin والعيش فيه باستمرار ، ومن الواضح أنها ليست فكرة جيدة.

majkinetor شكرا!
:)

يجب أن يكون sudo هو البديل CLI لموجه التحكم في حساب المستخدم. لم يكن Windows ، حتى وقت قريب ، متوافقًا مع CLI ، ولكن الآن أعتقد أننا بحاجة إلى هذا. لقد حان الوقت الذي يمكنك فيه عمل 100٪ من مهام Windows في shell فقط - أنا شخصياً أستخدم shell والمتصفح ، ولا شيء آخر.

majkinetor : على حد علمي ، فإن الطريقة الوحيدة لبدء عملية مرتفعة هي من خلال موجه التحكم في حساب المستخدم.
FWIW: يمكنك القيام بذلك على النوافذ دون تغيير بوويرشيل باستخدام ShellExecuteEx.
ومع ذلك ، إذا كنت تتوقع إعادة بث النتائج ؛ إنها قصة مختلفة تمامًا.

بقدر ما أعلم ، فإن الطريقة الوحيدة لبدء عملية مرتفعة هي من خلال موجه UAC.

يمكن استبعاد تطبيقات محددة من UAC والتي يمكن أن أفترض بعد ذلك التعامل مع الارتفاع بطريقتها الخاصة.

أردت أن أقدم الحل / الحل البديل لـ Sudo على Windows. سيكون موضع ترحيب أي ردود فعل / نقد. إذا لم يكن من المناسب نشر هذا النوع من الأشياء هنا ، فأنا أعتذر مقدمًا.

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

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

هناك ثلاث وظائف في Sudo Module:

• جلسة سودو الجديدة
• إزالة- SudoSession
• بدء جلسة سودو

Start-SudoSession (الاسم المستعار "sudo") مخصص للأوامر لمرة واحدة التي تحتاج إلى رفعها. سيطالبك ببيانات الاعتماد ويعطيك موجه UAC قبل تنفيذ الأمر.

.مثال

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

New-SudoSession إذا كان لفتح جلسة ElevatedPSS التي يمكن فيها إدخال أوامر مرتفعة. الفكرة هي أنه في نص أطول يحتوي على عمليات متعددة تتطلب ارتفاعًا ، يمكنك إنشاء جلسة 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 جلسة ElevatedPS التي أنشأتها وظيفة New-SudoSession. الفكرة هي وضع هذا في نهاية البرنامج النصي الخاص بك ، وعند هذه النقطة ستتلقى مطالبة UAC. لذا ، في المجموع ، لتشغيل أي عدد من العمليات المتزايدة في نص برمجي معين ، ستتعرض فقط لمطالبات UAC - أحدهما لفتح جلسة ElevatedPS والآخر لإغلاقه. استخدام Remove-PSSession:

.مثال

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

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

تحت الغطاء ، إليك ما تفعله من جلسة PowerShell غير مرتفعة (إذا كانت الجلسة مرتفعة بالفعل ، فلن تفعل شيئًا):

• يتحقق للتأكد من تمكين WinRM / WSMan وتهيئته للسماح بمصادقة CredSSP (إن لم يكن كذلك ،
  يتم إجراء تغييرات التكوين)

• التحقق من كائن نهج المجموعة المحلي ...

  تكوين الكمبيوتر -> القوالب الإدارية -> النظام -> تفويض بيانات الاعتماد -> السماح بتفويض بيانات اعتماد جديدة

  ... للتأكد من تمكينه وتكوينه للسماح بالاتصالات عبر WSMAN / LocalHostFQDN

• ينشئ جلسة PSS مرتفعة باستخدام New-PSSession cmdlet

• لتشغيل التعبير الذي تم تمريره إلى المعلمة -Expression في Elevated PSSession

• يزيل جلسة PSS المرتفعة ويعيد جميع التغييرات التي تم إجراؤها (إن وجدت) إلى نهج المجموعة المحلية وتكوين WSMAN / WinRM.

تحرير: تم تحديث مثال إزالة-جلسة SudoSession.

pldmgg لا أرى الترخيص الذي تحته الكود الخاص بك ، لذا لا يمكننا حتى النظر إلى ما قمت به. هل يمكنك إضافة ملف LICENSE؟ سيكون MIT أكثر ودية ويسمح لنا باستخدام التعليمات البرمجية الخاصة بك أو الاشتقاق منها. شكر!

pldmgg متابعة لما ذكره @ SteveL-MSFT ، دليل رائع لمساعدتك خلال هذه العملية هو https://choosealicense.com/.

tl ؛ dr - من الصعب أن تخطئ في التراخيص التالية:

• Apache 2.0
• معهد ماساتشوستس للتكنولوجيا

المزيد من التفاصيل

يتمتع Apache 2.0 ببعض نقاط القوة الإضافية عليه مقارنة بـ MIT ، ولكن بشكل عام ، فهي متساهلة للغاية ويمكن استخدامها بسهولة مع تراخيص أخرى مفتوحة المصدر وصديقة للأعمال. إذا اخترت أي تراخيص حقوق متروكة (GPL) ، فلن يمكن استخدام الكود مع أدوات أخرى دون نقل تلك الأدوات الأخرى إلى ترخيص GPL (المعروف أيضًا باسم الترخيص الفيروسي - LGPL هو الاستثناء هنا ، حيث يمكن للوحدات / الثنائيات المرخصة من LGPL يتم وضعها بجوار الأدوات الأخرى دون الحاجة إلى تغيير الترخيص للرمز الآخر).

pldmgg أيضا ، جدا ، رائع جدا!

ferventcoder شكرا للإشارة https://choosealicense.com! كما توقعتم يا رفاق (+ @ SteveL-MSFT) ، لم أكن متأكدًا حقًا من الترخيص الذي يجب اختياره. لقد قمت بتحديث الريبو الخاص بي بالكامل لاستخدام Apache 2.0 ، وقمت بتحديث Sudo.psd1 للإشارة إلى Apache 2.0 (في مستودع git وكذلك معرض PowerShell). آمل أن يكون هذا مفيدًا للناس! نرحب بكل النصائح / النقد!

@ SteveL-MSFT هل يمكنك استخدامه إذا كان الترخيص هو Apache 2.0؟ إذا كنت بحاجة إلى أن يكون معهد ماساتشوستس للتكنولوجيا ، فأخبرني وسأقوم بالتحديث.

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 أو "حارس الاعتماد" الجديد)

ملاحظة: أصبحت هذه المقالة مرجعًا لي لـ PowerShell Security (وهو المكان الذي علمت فيه حول Credential Guard) .. أوصي به بشدة .

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

بالنسبة إلى الإصدار 6.0.0 ، أعتقد أن ما سننتهي إليه هو:

وظيفة نصية تسمى sudo موجودة فقط على Linux (نحن نؤجل دعم رفع Windows). إذا كانت الوسيطة عبارة عن cmdlet / scriptblock ، فستكون sudoowershell بهذه الوسائط. هذا يعني أنه في الوقت الحالي ، لن تعمل كائنات خطوط الأنابيب. إذا كانت الوسيطة أمرًا أصليًا ، فنحن نمررها مباشرة إلى sudo.

بعد الإصدار 6.0.0 ، نود الحصول في النهاية على تجربة مثل:

Get-Item foo.txt | sudo Remove-Item

وجعله يعمل على كل من Windows و Linux. cc joeyaiello

استنادًا إلى مناقشة @ PowerShell / بوويرشيل-جنة ، هذا ليس مطلوبًا لـ 6.0.0 والتوصية هي الاستثمار في أمر cmdlet من النوع Invoke-AsUser

لتغيير الارتفاع بشكل عام ، ستحتاج إلى شيء به setuid bit تحت UNIX وسيكون sudo نفسه. sudo هو نظام ثنائي خاص لا يمكن محاكاته بسهولة ويجب عدم محاكاته من أجل الأمان. يرجى السماح باستخدام sudo الفعلي لتشغيل مثيل مؤقت من powerhell يقوم بتشغيل الأمر المعني. أيضًا ، فإن sudoing shell بالكامل أمر غير آمن إلى حد ما نظرًا لأن المرء قد ينسى shell مفتوحًا على خادم بعيد. sudo لديه آلية لتنسى أن المستخدم ارتقى بعد بضع دقائق مما يحمي الجهاز على المدى الطويل. سيسمح حل هذه المشكلة لمزيد من الأشخاص باستخدام بوويرشيل في الإنتاج على خوادم لينكس. كما تبدو الأمور ، سيبقى بوويرشيل حداثة هامشية لأن الأمن له أهمية قصوى في الإنتاج.

borgdylan اليوم ، يمكنك عمل sudo pwsh -c foo داخل PowerShell Core (أو فقط sudo nativecmd ). أعتقد أن الرغبة في أن تكون قادرًا على sudo أمر cmdlet داخل جلسة PowerShell Core موجودة. نحن لا نحاول إعادة إنشاء sudo هنا ، ولكن بدلاً من ذلك نحاول إعادة إنشاء بعض السكر التركيبي لتسهيل استخدامه.

مع # 1527 وهذه المشكلة يتم دفعها إلى أبعد من ذلك ، بدأت أتساءل: هل الجميع مرتاح حقًا لتسجيل الدخول إلى جلسات الجذر للقيام بأشياء المسؤول؟ لا توجد طريقة مناسبة عمليًا لاستدعاء أوامر PowerShell عندما يكون PS متورطًا بأي شكل من الأشكال.

MathiasMagnus لم أختبر هذا تمامًا ، ولكن يمكنك تكوين أوامر شائعة أو مستخدمة بشكل متكرر لعدم طلب كلمة مرور على sudo. لاختبار أضفت هذا مع visudo:

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

تمكنت بعد ذلك من الاتصال بـ sudo pwsh -c 'cat /etc/sudoers' عبر جلسة PowerShell SSH عن بُعد. اعتمادًا على كيفية قيامك بالأمان وما تقوم بتكوينه بالضبط في sudoers (على سبيل المثال ، All=(ALL:ALL) مفتوح قليلاً ...) قد يكون هذا آمنًا أو خطيرًا.

إذا كنت تستخدم نظام ssh إلى Linux (على سبيل المثال bash shell بدلاً من PowerShell SSH عن بُعد) ، فيمكنك تشغيل sudo بكلمة مرور عادية داخل pwsh بقدر ما أستطيع أن أقول.

ليس كثيرًا أنه من المستحيل ، فقط أن الحلول الحالية تأتي مع بعض الأمتعة.

لا يزال MathiasMagnus # 1527 مستهدفًا 6.1.0 نظرًا لعدم وجود حل بديل جيد لذلك. بالنسبة لأوامر cmdlets ، تتمثل المشكلة الرئيسية في تعقيد خطوط الأنابيب من / إلى sudo'd cmdlet. للعمليات الفردية sudo pwsh -c قابل للتطبيق. بالطبع إذا قام شخص ما من المجتمع بتقديم عرض عام ، فسيسعدنا أكثر من تناوله.

على Windows ، هذه مشكلة لا أعتقد أنه يمكن حلها دون رفع اتصالات ssh ، والتي تتطلب بعد ذلك طريقة للارتقاء من سطر الأوامر.

أعلم أنه من السهل أن أتحدث عن الأشياء التي لا تعمل ولا تتخذ أي إجراء ، لكن خبرتي تكمن في مكان آخر. أساهم في الغالب في مكتبات C ++ و GPGPU و Vcpkg للقيام بالكثير من عمليات نقل CMake. لم أكتب مطلقًا C # ولا أعتقد أنني سأمتلك القدرة على ذلك. ومع ذلك فأنا أدير مجموعة صغيرة من حوالي 12 آلة. إنه على حدود كونه قابلاً للإدارة يدويًا ، لكن قدرة sudo مفقودة بشكل خطير ، هذا إذا لم أكن أنوي إنشاء تسجيل دخول للمستخدم الجذر على Ubuntu ، وهو أمر يثير الاستياء. قد يكون DSC Core حلاً ، ولكن على الرغم من الإعلان عنه قبل عام ، فقد تم تأخيره مؤخرًا إلى أجل غير مسمى.

إن PowerShell Core على Linux كما هو قائم حاليًا عالق نوعًا ما بين الطريقة الآلية للقيام بالأشياء والأسلوب المخصص المألوف لدى مسؤولي نظام Linux. آمل أن يجد شخص ما الوقت لحضور هذه القضية.

MathiasMagnus هذا شيء يريده الجميع ، لكنه ليس مشكلة بسيطة لحلها. لاحظ أن استخدام sudo ضد الأوامر الأصلية يعمل بشكل جيد ، فهو في الحقيقة غير متاح لتشغيل sudo مقابل أوامر cmdlets. الحل هو استدعاء pwsh داخل pwsh:

sudo pwsh -c إزالة العنصر شيء

المضاعفات الرئيسية هي عندما يكون هناك شيء داخل خط الأنابيب:

get-item foo * | sudo إزالة العنصر

@ SteveL-MSFT على الأقل المفهوم ليس بهذا التعقيد. من فضلك قل لي ما هو رأيك.

نحتاج ببساطة إلى مجموعة من ثنائيات sudo و su و تسجيل الدخول للتعامل مع جميع الحالات.

يجب أن تفعل:

• قم بإنشاء مقبس يونكس لعمليات الاسترجاعات واسمح فقط للمستخدم الوجهة بالوصول إليه.
• تحقق من السماح للمتصل بالوصول إلى sudo (أعتقد أنه يمكن ببساطة نسخ الكود المصدري لـ su و sudo وتسجيل الدخول )
  
  
  
  • إذا كان / etc / sudoers موجودًا ، فيجب تحليله
    
    
    
    
    
    • أوامر محددة فقط
    
    
    
    • باستخدام كلمة مرور المستخدمين الوجهة
    
    
    
    • بدون التحقق من صحة بيانات الاعتماد (بدون كلمة مرور)
    
    
    
  
  
  • إذا لم يحدث ذلك ، يحتاج المرء إلى استدعاء pem للتحقق مما إذا كان المستخدم "يعرف" بيانات اعتماد جذر المستخدم مباشرة.
  
  
  • إذا كان لا يعرف أيضًا بيانات اعتماد المستخدمين الوجهة ، فقم برفض الوصول ورمي استثناءً في بوويرشيل.
  
  
• إذا نجح التحقق من الصحة ، نحتاج إلى تبديل سياق المستخدم إلى المستخدم الجذر أو المستخدم الوجهة.
• بمجرد تبديل سياق المستخدم ، تحتاج العملية الجديدة إلى إعادة الاتصال إلى powerhell الأصلي الذي يعمل عن طريق توصيله بمقبس unix.
• إذا قام المستخدم بإدخال "خروج" ، فإننا نشير عبر مقبس يونكس ، إلى أننا انتهينا ومع خروجنا ، سيعود المستخدم تلقائيًا إلى امتيازات المتصلين ، لذلك نحتاج فقط إلى powerhell الاستضافة لعرض موجه أو تنفيذ التالي تعليمات.
• إذا تم بدلاً من ذلك إنهاء powerhell المضيف ، يتم إغلاق مقبس unix ويجب أن يوقف powerhell المرتفع التنفيذ وينتهي ، تمامًا كما لو أغلق أحد الجهاز.

سيبدو تدفق التنفيذ كما يلي:
PWSH (يُنشئ socket /proc/self/change-user.socket) => PWSH-SU (يتم استدعاؤه باستخدام المقبس ومستخدم الوجهة كمعامل ؛ تم ضبط PWSH-SU على suid للتشغيل كجذر بحد ذاته) => PWSH أثناء اتصال مستخدم الوجهة إلى مقبس يونكس.

الجزء الأكثر استهلاكا للوقت هو السماح بوويرشيل بالاتصال داخليا عبر مقبس يونيكس. لا يكفي مجرد إعادة توجيه ربط الإدخال والإخراج لتطبيقات يونكس الأخرى ، لأننا نتعامل مع الكائنات وليس فقط مع السلاسل عند استدعاء الأنابيب.

لماذا نستخدم جميع الثنائيات الثلاثة؟
مطلوب sudo للسماح لعدة مستخدمين بالتبديل إلى سياق الجذر دون فقدان إمكانية التدقيق .
يتم استخدام su للتبديل إلى أي مستخدم آخر باستخدام بيانات اعتماد المستخدمين الوجهة.
يتم استخدام تسجيل الدخول لإنشاء جلسة تسجيل دخول جديدة بالكامل.
يمكن أن يكون الحصول على كل هذه الوظائف أيضًا في بوويرشيل مفيدًا في كثير من الحالات ، مقارنةً بوظيفة واحدة فقط.

يمكن أن يؤدي استخدام الأنابيب إلى جعل هذا يعمل على Windows أيضًا بطريقة أقل إثارة للدهشة وأكثر ملاءمة - أكره أن أحصل على غلاف آخر به جميع البرامج النصية لـ "sudo" + نقرات UAC ولكن باستخدام أنابيب مثل هذه ، يمكن القيام بذلك داخل نفس الغلاف فقط مثل على لينكس من خلال التواصل عبر الأنبوب مع مترجم آخر يعمل بالفعل كمسؤول وربما تنفيذ بعض عناصر sudo الحقيقية (مهلة فورية على سبيل المثال أو ملف sudoers بأوامر كبديل لنقاط نهاية powerhell المخصصة)

أنا سعيد حقًا برؤية الأفكار حول هذا الأمر ، ولكن فيما يتعلق بالتنفيذ الفعلي ، يبدو لي أننا نتقدم قليلاً على أنفسنا. أول شيء هو أن النظام يحتاج إلى طريقة لإنشاء عملية عالية ، خيط ، أيًا كان من عملية غير مستحقة. لا يمكن حل أي من مخاوف cmdlet حقًا إذا لم نتمكن من إنشاء مثيل مرتفع من PowerShell للبدء به ، دون المرور عبر UAC. IMO ، يجب أن يكون السيناريو الأول الذي يجب تناوله هنا - لديك جلسة SSH محدودة - كيف يمكنك تنفيذ تنفيذ عادي بأذونات المسؤول؟

لقد بدأت تجربة هذا هنا (تم كسره حاليًا لأنني كنت أعيد بناءه ، لكن المفهوم يعمل) ، لكنني لا أعتقد أن تطبيق جهة خارجية هو الحل الحقيقي. أود أن أرى Windows يشحن ملف 'sudo' exe أولاً. يمكن أن يكون هذا بسيطًا مثل تمكين runas لإنشاء عملية عالية مع مطالبة بيانات الاعتماد ، ولكن بدون الخطوة الأولى ، كل هذا نظري.

لا يمكن حل أي من مخاوف cmdlet حقًا إذا لم نتمكن من إنشاء مثيل مرتفع من PowerShell للبدء به ، دون المرور عبر UAC

أحد الاحتمالات للقيام بذلك يتضمن استخدام مهمة مجدولة مع خيار "التشغيل بأعلى امتياز".

نعم ولكن لإنشاء ذلك ، يجب أن يكون لديك بالفعل أذونات المسؤول الصحيحة؟ هذا ما يفعله psexec. بقدر ما أعرف ، في الوقت الحالي ، عليك أن تمر في مرحلة ما عبر UAC. أود أن أرى هذا التغيير ، ومع رفع مستوى جميع جلسات SSH ، فهو نوع من القلق الأمني. إذا حاولت بعض البرامج المخططة إدخال SSH في جهاز Windows الخاص بي ، على سبيل المثال من جهاز كمبيوتر آخر حيث تم إعداد مفتاح خاص (أو سيناريو الاسترجاع) ، فيمكنه فعل أي شيء يريده.

parkovski كان الحل الخاص بي هو Linux / MacOS وجميع أنظمة تشغيل NIX الأخرى فقط. لا يدعم Windows SUID و GUID.
نظرًا لأن sudo حاليًا غير موجود أيضًا على Windows ، فهو خارج نطاق هذه المشكلة بالنسبة لي.

ولحل مشكلة UAC ، يجب على Windows تنفيذ SUID و GUID في المستقبل. كل شيء آخر هو مجرد حل بديل لمشكلة طويلة الأمد ...

نعم ولكن لإنشاء ذلك ، يجب أن يكون لديك بالفعل أذونات المسؤول الصحيحة؟

صحيح ، لكنه لا يؤدي إلى ظهور نافذة UAC المنبثقة.

يمكن أيضًا تخطي UAC بالطريقة الرسمية باستخدام مجموعة أدوات توافق التطبيقات من Microsoft.

لا يدعم Windows SUID و GUID.

لا يتعين على Windows دعمه والمفهوم غير صالح على نظام التشغيل هذا.
يعتمد نموذج الإذن الخاص بها على ACL ولا توجد ملكية مجموعة واحدة.

كما أنه ليس من الضروري أن يكون نسخة طبق الأصل من sudo كاملة على النوافذ ، بل إنها طريقة أكثر ودية لاستدعاء أوامر المسؤول.

أعتقد أنه من الجيد تأجيل دعم Windows حيث ربما اعتاد مستخدمو Windows على فتح جلسة PowerShell مرتفعة اليوم بينما يتوقع مستخدمو Linux العمل بدون جذر و sudo حسب الحاجة. نريد فقط التأكد من أن أي تصميم لا يمنع دعم Windows في المستقبل. من المحتمل أيضًا أن أركز على تمكين sudo للجذر بدلاً من أي مستخدم تعسفي لتبسيطه وأعتقد أن هذا يمثل 90 +٪ من الاستخدام.

@ SteveL-MSFT

قد يركز أيضًا على تمكين sudo للجذر بدلاً من أي مستخدم عشوائي

أعتقد أن هذا لن يحدث فرقًا كبيرًا ، ولكنه يوفر تجربة su / sudo الكاملة للملخص الذي أشرت إليه أعلاه ، حيث أن تبديل سياق المستخدم إلى الجذر هو تقريبًا نفس التبديل إلى أي مستخدم آخر.

أعتقد أنه من الجيد تأجيل دعم Windows لأن مستخدمي Windows ربما اعتادوا على فتح جلسة PowerShell مرتفعة اليوم

غالبية الأشخاص الذين عملت معهم يقومون بتعطيل التحكم بحساب المستخدم إذا أمكنهم ذلك.

لسوء الحظ ، هذا ليس خيارًا حقًا في العديد من البيئات ، وأشك كثيرًا في أن 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". لا يغطي هذا حالة" القدرة على sudo الأمر cmdlet داخل جلسة PowerShell Core موجودة "لكل https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -354853084

ومع ذلك ، أتساءل عن مدى أهمية إعطاء السياق المرتفع الجلسة الكاملة لأمر الاستدعاء. في الأصداف الأخرى ، لا يزال sudo يشغل الأمر المتوفر في سياق جديد.

لقد قمت بتطبيق sudo أساسي يعمل بشكل جيد لتشغيل الأوامر كمسؤول على Windows. لست متأكدًا مما إذا كان هذا سيعمل أيضًا على نظام التشغيل Linux / mac ، لأنني لا أعرف ما إذا كان "RunAs" يرتفع بشكل صحيح أم لا على تلك الأنظمة الأساسية.

عدل ملفك الشخصي:

PS > notepad $PROFILE

أضف الوظيفة التالية sudo :

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

ثم استدعي في قوقعتك. يدعم أوامر cmdlets والملفات التنفيذية وأي شيء يمكن كتابته عادةً في موجه 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

قم بإزالة "-NoExit" من وظيفة sudo إذا كنت تفضل إغلاق نافذة المسؤول عند الانتهاء.

vsalvino هذا حل بديل مفيد عندما تكون واجهة المستخدم الرسومية متاحة ومفيدة في هذه الأثناء ، ولكن هذا لا يزال غير sudo حقيقي لأنه لا يعمل بدون الوصول إلى واجهة المستخدم الرسومية. في shell البعيد (ssh) ، الطريقة الوحيدة حرفياً لإنجاز هذا العمل هي الخدمة والعميل كما حاولت أن أوضح هنا .

لمعالجة بعض الاقتراحات الشائعة ، لأنني صدقني لقد نظرت في كل الاحتمالات:

• تعطيل التحكم بحساب المستخدم ليس حلاً. إنه حل بديل يمكن إجراؤه كخيار شخصي ولكنه ليس حلاً عامًا لهذه المشكلة.
• أي شيء ينبثق UAC (كل نص برمجي "sudo" رأيته) ليس حلاً ، بما في ذلك القيام بذلك مرة واحدة لبدء جلسة عمل بعيدة.
• أي شيء يتطلب واجهة المستخدم الرسومية _على الإطلاق_ ليس حلاً. لنفترض أننا نستخدم ssh هنا وأن واجهة المستخدم الرسومية غير متاحة.
• أي شيء يتطلب تغييرات كبيرة في Windows ليس حلاً. لا يمكننا الاعتماد على تحول UAC إلى شيء أفضل.
• حتى البرنامج الثنائي الموقع من Microsoft ليس حلاً ، لأنه لن يعمل عندما يتم تعيين UAC على مستوى عالٍ (لقد أخطأت في الملف التمهيدي wsudo ؛ سأقوم بتصحيحه لاحقًا).
• الحل الحقيقي الوحيد لـ sudo على Windows هو الخدمة التي ترفع عمليات المستخدم إلى المصادقة الناجحة. أحب أن أسمع أفكارًا أخرى ولكن من فضلك قم ببحثك أولاً.

في الأساس ، سيتعين على شخص ما القيام بالكثير من العمل ، بأي حال من الأحوال حوله. ما نريده هو شيء ، بمجرد أن يدعم PowerShell هذا على نظام Unix ، يكون بمثابة بديل في نظام التشغيل Windows ، ويعمل كما تتوقع أن يعمل sudo (بدون واجهة مستخدم رسومية ، لا UAC).

هل يمكننا من فضلك توضيح نطاق هذه المسألة أولا؟ أعتقد أن العديد من الأشخاص يتحدثون عن مواضيع مختلفة في الوقت الحالي.
هل هذه المشكلة:
أ) حول تنفيذ sudo داخل بوويرشيل لأنظمة لينكس / ماك؟
ب) تنفيذ نسخة متماثلة sudo في النوافذ؟
ج) السماح برفع الامتيازات عند psremoting؟
د) السماح بانتحال صفة مستخدمين آخرين على النوافذ؟
هـ) السماح بالتبديل من حساب مستخدم غير متميز إلى حساب مستخدم متميز؟
و) شيء مختلف تماما؟

أ) https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067
بالنسبة إلى ب) مثل (يحتوي Windows أيضًا على مآخذ unix) ، ولكن بدلاً من ثنائي suid يجب أن يتم إنتاجه بواسطة خدمة (تعمل ضمن مستخدم لديه امتياز "يعمل كجزء من نظام التشغيل" مثل نظام المستخدم) و تحتاج هذه الخدمة أيضًا إلى التحقق من الامتيازات. أو قم بتطبيق مفهوم SUID / GUID على النوافذ.
ج) ليس مطلوبًا لديك بالفعل أعلى الامتيازات عند الاتصال عن بُعد. لا يوجد فصل امتياز عند الوصول إلى المضيفات البعيدة (كان هناك بالفعل بعض تجاوزات UAC لاسترجاع الاسترجاع المحلي التي عملت بهذه الطريقة).
بالنسبة إلى د) يمكن أيضًا اتباع النهج من a / b ، لكنني لا أعرف كيف يجب أن يعمل ذلك عند محاولة الوصول إلى موارد الشبكة ، دون معرفة بيانات اعتماد المستخدمين أو إنشاء واجهة مصادقة جديدة للنوافذ / الدليل النشط.
بالنسبة إلى e) تمامًا مثل b ، ولكن التحقق من بيانات الاعتماد مطلوب أيضًا ، وبدلاً من ذلك ، يمكن فك واجهة برمجة تطبيقات runas للسماح لشخص يعرف اسم المستخدم وكلمة المرور بالحصول على رمز مستخدم جديد والتحكم في هذه العملية. (من غير المحتمل مراعاة مفاهيم واعتبارات أمان UAC ، لذلك عدنا إلى ب).

يجب أن تتعلق هذه المشكلة في IMO بتنفيذ sudo في PowerShell حيث توجد الوظيفة الأساسية بالفعل. من المحتمل أن تكون المناقشة حول مكافئ sudo لنظام التشغيل Windows أكثر ملاءمة في هذه المشكلة الطرفية .

من المحتمل أن تكون المناقشة حول مكافئ sudo لنظام التشغيل Windows أكثر ملاءمة في هذه المشكلة الطرفية.

لماذا قد يكون تطبيق Terminal مكانًا أفضل لمناقشة sudo ، بالنظر إلى أنه الواجهة الأمامية الأخرى الوحيدة لعالم CLI؟ بنفس المنطق يمكنك تقديم تذكرة في مستودع ConEmu.

يجب أن تتعلق هذه المشكلة في IMO بتنفيذ sudo في PowerShell حيث توجد الوظيفة الأساسية بالفعل.

إحدى نقاط Powershell التالية هي مشاكل التوافق الأقل بين الأنظمة التي تستخدمها. فيما يتعلق بذلك ، فإن القيام بشيء ما فقط على النظام X هو أمر غير مقبول من IMO.

أنا كمستخدم CLI لا يمكن أن أهتم كثيرًا إذا كان sudo ممتلئًا باستخدام ملف suders أو بعض النوافذ على حدٍ سواء. Sudo هي مجرد واجهة لميزات رفع مستوى نظام التشغيل. يمكن جعل هذه الواجهة تعمل بالقرب من نفس الشيء بغض النظر عن "الواجهة الخلفية".

خلاف ذلك ، نقطة parkovski حول حوامل واجهة المستخدم الرسومية - أود فقط إضافة Windows Core من بين الأسباب.

لماذا قد يكون تطبيق Terminal مكانًا أفضل لمناقشة sudo ، بالنظر إلى أنه الواجهة الأمامية الأخرى الوحيدة لعالم CLI؟ بنفس المنطق يمكنك تقديم تذكرة في مستودع ConEmu.

لأن هذا الريبو ليس مجرد "تطبيق طرفي" ؛ يمتلك الفريق الذي يديره بشكل أساسي أجزاء وضع النص في Windows وقد قال بالفعل إنهم مهتمون بتنفيذ sudo عندما يمكنهم العثور على الوقت. من ناحية أخرى ، لم يقدم أي شخص من فريق PowerShell ولا ConEmu.

السبب الذي يجعلني أعتقد أن Windows sudo خارج النطاق هنا هو أننا قررنا بالفعل أن القيام بذلك بشكل صحيح هو قدر كبير جدًا من العمل ومتعامد مع PowerShell نفسه. يمكن أن يستخدمه PowerShell عندما يكون موجودًا ، ولكنه حقًا مكون مستقل عن أي غلاف معين.

من ناحية أخرى ، فإن قدرة PowerShell على تشغيل أوامر cmdlets من خلال ثنائي sudo ، بغض النظر عن النظام الأساسي أو كيفية عمل هذا الثنائي بالفعل ، هو شيء يجب أن يكون جزءًا من PowerShell ، الذي ينتمي هنا.

أنا كمستخدم CLI لا أهتم كثيرًا إذا كان sudo ممتلئًا بالكامل باستخدام ملف suders أو بعض النوافذ على حدٍ سواء. Sudo هي مجرد واجهة لميزات رفع مستوى نظام التشغيل. يمكن جعل هذه الواجهة تعمل بالقرب من نفس الشيء بغض النظر عن "الواجهة الخلفية".

نعم ، يجب بالتأكيد. الأمر مجرد أن sudo غير موجود حتى الآن على Windows ، وسيستغرق الكثير من العمل ، وربما لن يكتبه فريق PowerShell. عند وجود مثل هذا الشيء ، دعونا نأمل أن يقوم PowerShell بتنفيذ ذلك بطريقة تعمل على نظام Windows أيضًا.

على أي حال ، سأؤجل المزيد من التعليقات حتى نحصل على رد رسمي هنا لأن هذه القضية تسير في جميع أنواع الاتجاهات المختلفة.

أي رأي في هذا؟
http://blog.lukesampson.com/sudo-for-windows
تم التثبيت بـ scoop install sudo ، إنه أقرب ما يمكنني التفكير فيه. إنه يعمل مثل أوامر التشغيل unix sudo مع الارتفاع. أستخدمه مع نقطة أو وحدة التثبيت لجميع المستخدمين.

لوك سامبسون - سودو لنظام التشغيل Windows

سودو لنظام التشغيل Windows

@ Restia666Ashdoll إذا تمت إعادة تسميته إلى Invoke-ElevatedCommand فلا بأس بذلك.
هذا لأن sudo ليس مسؤولاً فقط عن رفع الأوامر ، ولكن أيضًا عن انتحال صفة المستخدمين وامتيازات "إسقاط" ( sudo -u nobody command ). كما أثبتت إعادة استخدام الأسماء الموجودة بالفعل أنها فكرة سيئة ، خاصة إذا كانت الوظائف والمعلمات مختلفة.
لقد أوضحت أعلاه ما سيبدو عليه sudo الحقيقي مع انتحال الهوية وكيف يمكن أن يعمل.

@ Restia666Ashdoll يرجى قراءة هذا التعليق في هذا الموضوع.

parkovski Thats مجرد غلاف لـ -Verb RunAs ، والذي يعمل فقط مع بعض الأوامر. يمكن استخدام الشخص الذي ربطته مع كل شيء تقريبًا. على سبيل المثال ، أستخدمه على هذا النحو - sudo pip install httpie .

أنت لم تقرأ رسالتي أليس كذلك؟

لا أفترض أن هناك أي طريقة لتحرير العنوان ليشمل شيئًا مثل "ليس SUDO ON WINDOWS DISCUSSION"؟ أعلم أنني لست ملزمًا شخصيًا بالاستمرار في الإجابة عن هذا السؤال ، لكن الناس يستمرون في الظهور بقول نفس الشيء دون إجراء أبحاثهم.

حاولت النقر فوق رابط إلغاء الاشتراك الخاص بهذا الرجل ، وللأسف لن يسمح لي بذلك دون تسجيل الدخول باسمه.

لقد أبلغت عن troymoore لـ GitHub بالفعل

أود أن أقترح حلاً فريدًا ومختلفًا لم أره نتحدث عنه هنا. ماذا عن استخدام شيء مثل الأنابيب المسماة لتسلسل الأوامر إلى عملية مرتفعة والتي تقوم بعد ذلك بإعادة إخراجها المتسلسل إلى عملية الاستدعاء؟

فيما يلي وحدة عاملة توضح كيفية عمل ذلك على NT: https://github.com/mmillar-bolis/Invoke-AsAdmin

إنه ليس مثاليًا ، بالطبع ، لكنه ينجز مهامًا بسيطة وتخطيطاً دون فتح وحدة تحكم أخرى. لا أنوي عرض هذا على أنه sudo-like في حد ذاته لأنني لا أعتقد أن استنساخ تصميم sudo سيكون أفضل حل طويل المدى ، لكنني اعتقدت أن اتباع نهج مختلف لمشكلة الارتفاع الغامضة قد يزيد من المناقشة البناءة.

تحرير: يجب أن أذكر أيضًا أن هذا لن يُنجز طلب parkovski لرفع UACless.

يبدو مثل JEA.
بالنسبة إلى التسلسل ، لا تدعم جميع الوحدات هذا.

يبدو مثل JEA.

نعم هذه هي الفكرة

بالنسبة إلى التسلسل ، لا تدعم جميع الوحدات هذا.

كما رأيت على الأرجح في الكود ، يتم تخفيف ذلك من خلال تدفقات النص التي تعيد بناء الكود على الطرف الآخر من الأنبوب. أعترف أن هذا بطيء ، لكنه مع ذلك حل جديد. كان ذكرك لـ JEA مرة أخرى عاملاً مؤثرًا هنا ؛ إذا كان جزء من الكود لا يحتاج إلى رفع ، فلا ينبغي أن يكون.

تهدف الوحدة إلى حل مشكلة محددة للغاية تتعلق برفع الأوامر التفاعلية داخل جلسات واجهة المستخدم الرسومية على NT ولا شيء أكثر من ذلك. بدأ الأمر منذ خمس سنوات قبل أن يتخيل أي شخص أن ssh الأصلي قد يكون شيئًا لـ NT. أتفق مع parkovski في أن هذه مشكلة تتعلق بكيفية معالجة NT للارتفاع ، لذلك بدون خدمة الاستماع إلى وتقديم شكل محدد من ارتفاع الأمر ، يكون من الصعب تحقيق سهولة استخدام مشابهة لـ sudo أو pkexec أو doas.

ومع ذلك ، بدلاً من الوقف بسبب مغالطة نيرفانا التي تنص على ضرورة وجود تطبيق يشبه sudo على NT قبل أن يتمكن PowerShell من دعم أي شكل من أشكال رفع الأمر ، فلماذا لا ندفع أولاً نحو أي شكل من أشكال الارتقاء التفاعلي لـ JEA داخل جلسة shell؟

هذا من شأنه على الأقل تعزيز ممارسات الأمان المحسنة في عالم NT. لماذا لا يتم تنفيذ كل من cmdlet للتشغيل بشكل تفاعلي وواحد لبدء جلسة وحدة تحكم منفصلة؟ أو أفضل من ذلك ، ما عليك سوى الترويج للطرق الحالية لبدء جلسة مرتفعة جنبًا إلى جنب مع مجموعة أكثر تقشفًا من أوامر cmdlets مع حالات استخدام مختلفة؟ إنها على الأقل خطوة للأمام.

قد أضيف أيضًا أنه حتى مكتبة Python Elevate لا يمكنها فعل ما تفعله هذه الوحدة. هل وجدت وحدة أخرى لا تعمل معها بالفعل؟ لأن وجهة نظري الرئيسية هي أنه ربما يمكن للعقول الأكثر ذكاءً من عقلي أن تأخذ هذه الوحدة وأفكارها وتعمل معها في اتجاه يناسب NT. بعد ذلك ، قد يكون لدينا بدايات منصة لـ NT و * nix للالتقاء في المنتصف ، مما يسمح لنا بمراجعة تنفيذ أكثر شيوعًا لـ PowerShell لرفع الأوامر.

هذا هو سنتي ، على الأقل. لكن بعد الاطلاع على الكود ، إذا شعر المرء أن الأفكار الموجودة بداخله ليست جيدة ، فسوف أفهم. لم أر أي شخص حتى يحاول شيئًا كهذا حتى الآن.

سأتراجع عن أحزاني المحبطة لشرح نقطة sudo لمدة دقيقة لأنه (أ) نعم هذه مشكلة صعبة للغاية ، (ب) لا يمكن حلها بشكل صحيح إلا عن طريق MS (شكرًا لعدم كونك مفتوح المصدر ، Windows) ، (ج) من الرائع حقًا أن نرى أن الآخرين متحمسون لهذا أيضًا.

أعلم مدى صعوبة القيام بذلك بشكل صحيح لأنني بدأت في ذلك الطريق. لذا ، إذا كان الشيء الوحيد الذي يمنعنا من ذلك الآن هو مربع حوار UAC ، فليكن. بهذه الطريقة على الأقل يمكننا اختبار حل عبر النظام الأساسي بجهد بسيط.

ما أرغب في رؤيته شخصيًا من PowerShell هو دعم شامل لـ Unix sudo ، ولكنه مصمم لدعم بعض أشكال النص "pseudo-sudo" كما هو الآن بالإضافة إلى sudo الحقيقي المحتمل في المستقبل. فكرتي هي أنه إذا قام شخص ما بوضع نماذج أولية لكيفية عمل Windows sudo في النهاية ولكنه ترك قيود UAC ، فيجب أن يكون الأمر بسيطًا إلى حد ما ، ويعطينا شيئًا جيدًا كما هو الآن ، وعندما نحصل على الشيء الحقيقي يجب أن يكون جميلًا سيكون مجرد بديل بدون حجز مسبق.

من الواضح أن هذا يعني أن على شخص ما أن يأتي بنموذج يفهم أو على الأقل يترجم إلى كل من نموذج Unix uid / gid ونموذج Windows sid / acl. نأمل أن يحب هذا الشخص التحدي. سيتطلب تخمين هذا أيضًا إجراء بعض المحادثات مع فرق أمن الجهاز و windows داخل MS.

أعتقد أنه مع وجود العديد من الأشخاص الذين قاموا بإنشاء أفضل الحلول الخاصة بهم ، وأن دعم شيء كهذا يمكن أن يساعد في تصميم طريقة قوية للقيام بذلك ، فلماذا لا؟

Sidenote - قد يعتبر أي شخص يكتب نصوص الحل هذه أن ميزة المهلة الموجودة في sudo مزعجة مثل تلك النافذة المنبثقة.

يمكننا التفكير في Start-Process pwsh -NoNewWindow -Credential $cred . انها لا تعمل ولكن يمكن.

من الواضح أن هذا يعني أن على شخص ما أن يأتي بنموذج يفهم أو على الأقل يترجم إلى كل من نموذج Unix uid / gid ونموذج Windows sid / acl. نأمل أن يحب هذا الشخص التحدي. سيتطلب تخمين هذا أيضًا إجراء بعض المحادثات مع فرق أمن الجهاز و windows داخل MS.

يحتوي نظام التشغيل Unix أيضًا على قوائم التحكم بالوصول (acls) ، كما أن الويندوز لديها توافق مع posix ، وعلى الأقل إذا كانت مشتركة في المجال ، فهناك أيضًا سمة مجموعة أساسية يمكننا استخدامها (بالإضافة إلى سمات posix). سيحتاج فقط إلى أن يتم تنفيذه لعملاء windows غير المنضمين إلى المجال (أو يفترض الآن أن يكون User ).

لذلك فإن النموذج العام لأذونات يونكس وويندوز هو في الأساس:
قوائم ACL مع مستخدم مالك ومجموعة مالك مع بعض ACEs المتوقعة (مستخدم ، مجموعة وغيرها).

مما يمكننا تعيين أذونات يونكس على النحو التالي:
uid => المالك SID
gid => معرّف الأمان (SID) للمجموعة الأساسية للمستخدم الذي أنشأ الكائن.
user => معرف مالك المنشئ S-1-3-0
group => معرف مجموعة منشئي المحتوى S-1-3-1
other => العالم / الجميع S-1-1-0
يعد تعيين uids من قائمة التحكم في الوصول على نظام التشغيل Unix أكثر تعقيدًا بعض الشيء حيث نحتاج إلى اعتبار أن النظام قد يكون جزءًا من ldap أو دليل نشط أو أي دليل آخر. الحالتان الوحيدتان اللتان سأعتبرهما في نطاق بوويرشيل هما لا يوجد دليل ودليل ldap / نشط.
في الحالة الأولى ، أقترح استخدام S-1-6-1-uid و S-1-6-2-gid (بافتراض أن S-1-6 لا يزال متاحًا والفريق المسؤول على استعداد لتخصيصه لهذا الغرض ).
وبالنسبة للحالة الثانية ، نحتاج فقط إلى نوع من حل المعرّف من خلال الواجهة الخلفية للمصادقة. يعد خادم الدليل ldap / active مسؤولاً عن توفير معرّف الأمان (sid).
وأخيرًا ، هناك بعض الحالات الخاصة التي يجب تعيينها:
uid 0 => S-1-5-32-544
gid 0 => S-1-6-500 (و S-1-5-21 - * - 500)
يمكن إدارة معظم sids الأخرى المعروفة من خلال ملف تكوين أو من خلال واجهة برمجة تطبيقات من نوع ما (أو قم بإسقاطها فقط لأنها على الأرجح غير مستخدمة على أي حال)

إذا قمنا بذلك في shell build في أوامر مثل Get-Acl / Set-Acl ، فمن الممكن أن نبدأ في العمل على أنظمة unix دون معرفة كيفية تخزين الأذونات على القرص.

@ mmillar-bolis لقد اقترحت بالفعل طريقة باستخدام المقابس هنا: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

يمكننا التفكير في بدء العملية pwsh -NoNewWindow -Credential $ credit. انها لا تعمل ولكن يمكن.

تحديث: .Net Core (وأعتقد أن Windows API أيضًا) لا يسمح بتشغيل عملية جديدة مرتبطة بوحدة التحكم نفسها.

لذا فإن الطريقة الوحيدة التي يمكننا استخدامها هي خدمة Windows مرتفعة. ولكن علينا إنشاء مثل هذه العملية في "sudo" لتكون آمنة.
لذا سيكون الحل New-PSSession (أو الاستدعاء في PSSession) للمضيف المحلي ببيانات اعتماد مستخدم مرتفعة.

iSazonov أحد الأشياء الوحيدة التي تسمح لك https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

الآن بما أن windows تدعم مآخذ unix ، يمكننا استخدامها أو استخدام الأنابيب المسماة وستكون الخدمة المميزة مسؤولة عن التحقق من صحة بيانات الاعتماد وستحتاج إلى التشغيل طوال الوقت (مقارنةً بالاستدعاء عبر suid كما هو مذكور في النشر المرتبط لـ * nix oses) .

ربما تحتاج lsas / يمكن أن يتم تمديدها لتوفير إمكانات API للمصادقة هذه؟
وبهذه الطريقة يمكننا الحصول على انتحال كامل للهوية مع استمرار قدرتنا على الارتباط بأمان بوحدة التحكم نفسها وقبول المدخلات.

@ agowa338 اقتراحك "بحكم الواقع" هو PowerShell عن بُعد. تم تنفيذه بالفعل.

لكن

لذا سيكون الحل New-PSSession (أو الاستدعاء في PSSession) للمضيف المحلي ببيانات اعتماد مستخدم مرتفعة.

لا يعمل مع المضيف المحلي. يرمي فقط AccessDenied.

باستثناء حالة واحدة من هذه:

• UAC متوقف
• حاولت الاتصال بـ BUILDIN \ Administrator دون تمكين وضع موافقة المسؤول.
• العملية (بوويرشيل) مرتفعة بالفعل .

هنا شرح جيد لسبب ذلك بواسطة @ jborean93 : https://github.com/PowerShell/Win32-OpenSSH/issues/1308#issuecomment -448430464

لذلك نحن بحاجة إلى خدمة مميزة تعمل كوسيط أو تحتاج إلى تغيير إحدى واجهات برمجة التطبيقات ، ولكن هذا ليس شيئًا يمكننا القيام به داخل PowerShell / PowerShell وسنحتاج إلى تفويض من قبل موظفي Microsoft داخليًا.

@ agowa338 التعليق الذي

iSazonov : هل حاولت حتى إجراء الاتصالات عن بعد بوويرشيل تعمل للأسباب الموضحة أعلاه. تم حظر تخصيص إشارة الدخول بواسطة نظام التشغيل.

لا يسمح الاتصال عن بُعد لـ PowerShell بالمضيف المحلي بالحصول على امتيازات مرتفعة على الكمبيوتر المحلي.

ومع ذلك ، يمنحك الاتصال عن بُعد PowerShell امتيازات عالية على جميع المضيفين الآخرين في الشبكة باستثناء المضيف المحلي (على افتراض أنك عضو في Domain-Admins ، إلخ).

هذا هو السبب الذي يجعلنا نحتاج إلى مكافئ sudo على النوافذ. إذا كان العمل عن بُعد في PowerShell يتصرف بهذه الطريقة التي تعتقد أنه يفعلها ، فيمكن إغلاق هذه التذكرة عن طريق كتابة مثال في المستندات لأن الوظيفة موجودة بالفعل.

@ agowa338 لا يعمل من أجلك بسبب الحماية الأمنية. إنها ليست ميزة نظام التشغيل. يمكنك تكوين WinRM كما هو موضح في المستندات https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting . تشير المشكلة التي أشرت إليها أيضًا إلى أن هذا يعمل مع SSH (توجد الخطوات المشار إليها في المقالة).

لأن الوظيفة ستكون موجودة بالفعل.

الطلب هو بدء العمل "sudo Remove-Item foo.txt حيث يمتلك الجذر foo.txt".
لا يعمل ولكن نريد.
المشكلة تتكون من جزأين: نحوي السكر في اللغة والتنفيذ.

إذا كنت تفكر أكثر في اقتراحك ، فستكتشف أنك بحاجة إلى الحصول عليه لكل مستخدم / لكل جلسة / لكل مساحة تشغيل / لكل سياق نطاق بوويرشيل. ثم يتعين عليك معالجة متطلبات التوافق الأمني ​​وستحصل على "رفض الوصول" في التكوين الافتراضي. بعد ذلك ، سيكون اقتراحك هو نفسه الذي تم تنفيذه بالفعل عن بُعد في PowerShell.

about_Remote_Troubleshooting - بوويرشيل

لا يعمل من أجلك بسبب الحماية الأمنية. إنها ليست ميزة نظام التشغيل. يمكنك تكوين WinRM كما هو موضح في المستندات

iSazonov هل يمكنك توضيح ذلك أكثر قليلاً؟ يمكنني التحكم عن بعد في هذا الجهاز ومن أي جهاز إلى أي جهاز آخر في الشبكة ، ولكن من أي جهاز إلى مضيف محلي. ونعم قرأت تلك الصفحة.

الطلب هو بدء العمل "sudo Remove-Item foo.txt حيث يمتلك الجذر foo.txt".

بالنسبة للأنظمة التي لا تعمل بنظام التشغيل Windows ، يمكننا استخدام نهج مقبس unix لتنفيذ انتحال الهوية / الارتفاع من أجل الاتصال عن بُعد في powerhell.

هل يمكنك توضيح ذلك أكثر قليلاً؟ يمكنني التحكم عن بعد في هذا الجهاز ومن أي جهاز إلى أي جهاز آخر في الشبكة ، ولكن من أي جهاز إلى مضيف محلي. ونعم قرأت تلك الصفحة.

تستهدف معظم الهجمات ارتفاعات محلية. لذا فإن جميع التكوينات "آمنة بشكل افتراضي". WMI و WinRM و IIS loopback وما إلى ذلك - تعمل جميع الأنظمة الفرعية على تعطيل الميزات التي تسمح بالارتفاعات المحلية.
ليس من المهم جدا للمناقشة. حتى إذا كان الاتصال عن بُعد في PowerShell لا يسمح لنا بتنفيذ sudo افتراضيًا ، يمكننا تنفيذه معطلاً افتراضيًا أو السماح فقط بجلسة تفاعلية.

لقد بدأت في الحديث عن windows ، بالنسبة للأنظمة التي لا تعمل بنظام windows ، يمكننا استخدام نهج مقبس unix لتنفيذ انتحال الهوية / الارتفاع من أجل الاتصال عن بُعد بوويرشيل هناك.

يجب أن يكون لدينا نفس تجربة المستخدم لجميع الأنظمة الأساسية. حقا هناك PSRP يعمل على النقل - WinRM أو SSH. قالت منظمة أطباء بلا حدود إنهم يحبون SSH لكني لا أرى أي تقدم ملحوظ خلال العامين الماضيين. ومن غير المعقول أنهم يريدون بروتوكولًا ثالثًا في المستقبل القريب - الكثير من العمل (الحاجة إلى الحفاظ على التوافق مع الأنظمة القديمة).

تستهدف معظم الهجمات ارتفاعات محلية. لذا فإن جميع التكوينات "آمنة بشكل افتراضي". WMI و WinRM و IIS loopback وما إلى ذلك - تعمل جميع الأنظمة الفرعية على تعطيل الميزات التي تسمح بالارتفاعات المحلية.
ليس من المهم جدا للمناقشة. حتى إذا كان الاتصال عن بُعد في PowerShell لا يسمح لنا بتنفيذ sudo افتراضيًا ، يمكننا تنفيذه معطلاً افتراضيًا أو السماح فقط بجلسة تفاعلية.

حاولت تمكين ذلك منذ فترة ، وقيل لي مرارًا وتكرارًا من قبل العديد من الأشخاص الآخرين أن هذا مقيد بواسطة نظام التشغيل داخليًا وأنه غير ممكن بأي شكل من الأشكال دون وجود تطبيق يتعمق في الأجزاء الداخلية من Windows. في الواقع ، أشار الكثيرون إلى قيود windows api المشار إليها أعلاه واستخدموا ذلك كحجة لماذا لا يمكن أن يوفر powerhell مثل هذه الإمكانية. حتى أن شخصًا ما أشار إلى CVE حيث تمت إزالة ارتفاع الاسترجاع عمدًا. لذلك أعتذر عن النزول إلى حفرة الأرنب تلك أعمق قليلاً ، لكن ما الذي أحتاجه لتهيئته حتى يعمل؟ هل هذا موثق في أي مكان؟

يجب أن يكون لدينا نفس تجربة المستخدم لجميع الأنظمة الأساسية. حقا هناك PSRP يعمل على النقل - WinRM أو SSH. قالت منظمة أطباء بلا حدود إنهم يحبون SSH لكني لا أرى أي تقدم ملحوظ خلال العامين الماضيين. ومن غير المعقول أنهم يريدون بروتوكولًا ثالثًا في المستقبل القريب - الكثير من العمل (الحاجة إلى الحفاظ على التوافق مع الأنظمة القديمة).

حسنًا ، يجب علينا دفع أي من كلا الحلين إلى الأمام حيث يعمل كلاهما على أي منصة.

• PSRP: يعمل SSHing to localhost للارتفاع على نظامي التشغيل Windows و Linux ، لذلك باستخدام النظام الفرعي psrp لدينا بالفعل الأذونات الصحيحة ، لذلك يجب توحيد طبقة powerhell فقط للسماح بتمرير الكائنات. حق؟
• سيوفر استخدام مآخذ يونكس أيضًا وظائف مماثلة مثل الاتصال عن بُعد بوويرشيل ، ولكن مع وقت كتابة هذا التقرير ، افترضت أنه من الصعب القيام بالارتفاع المحلي دون أي نوع من الخدمات الإضافية التي تعمل كنظام محلي لأداء تبديل الرمز ...

لذلك ، نظرًا لأن الاتصال عن بُعد بوويرشيل موجود بالفعل (وأيضًا يعمل كيندا على ssh بالفعل) ، يجب أن نعطي الأولوية لهذا الحل على ما أعتقد.

حتى أن شخصًا ما أشار إلى CVE حيث تمت إزالة ارتفاع الاسترجاع عمدًا.

لا أستطيع أن أؤكد. أعتقد أن CVE يمكنه فقط تعطيل الاسترجاع افتراضيًا ولكن ليس على الإطلاق.
راجع أيضًا https://github.com/PowerShell/PowerShell/issues/3874#issuecomment -510715727

iSazonov : هذا لا يعمل ، فهو يوفر فقط رمز الوصول المنخفض الامتياز ولكن ليس رمز الوصول المرتفع (على سبيل المثال Mandatory Label\High Mandatory Level ). لا أحصل على أذونات إدارية من قوة امتياز منخفضة على الرغم من تعيين TrustedHosts على * بالنسبة لي. يكون رمز تسجيل الدخول دائمًا من النوع التفاعلي ، حتى بعد Enter-PSSession.
يمكنني في الواقع Enter-PSSession localhost -ScriptBlock {} لكن تمرير بيانات الاعتماد يتسبب في "رفض الوصول". ، كلا ، فإنه يرمي دائمًا عبارة "تم رفض الوصول" لأن النظام الآخر قد تم تعطيل uac.

لكنني جربته الآن أيضًا باستخدام SSH وهذا يعمل كما هو متوقع ، فهو يوفر الرمز المميز المرتفع ( Mandatory Label\High Mandatory Level ) مع نوع تسجيل الدخول Network.

لذلك في PSCore يمكننا الاعتماد على psrp للارتفاع (حتى محليًا من خلال Enter-PSSession -HostName localhost الذي يعمل أيضًا مع بيانات اعتماد صريحة يتم تمريرها.
حيث Enter-PSSession -ComputerName localhost -Credential $foo لا (حتى لو كان $ foo.Username هو نفسه المستخدم الحالي)

@ agowa338 أعتقد أنه لا ينبغي لنا مناقشة تجاوز ميزات أمان WinRM هنا (إنها منطقة حساسة للامتثال). يمكنني فقط الإشارة إلى (1) أنه بغض النظر عن البروتوكول ، يجب أن يظل الأمان على نفس المستوى ، مما يعني أن استرجاع SSH يجب أن يتصرف بنفس الطريقة التي يعمل بها WinRM مع مراعاة كيفية عمل الأجزاء الداخلية لـ Windows ، (2) يجب أن يعمل تنفيذ PS sudo أكثر أي وسيلة نقل.

iSazonov : لم أطلب أي استغلال ، ولكن فقط ما يجب تهيئته لتمكينه. كما أنك ستكون الوحيد الذي اكتشف كيفية تكوين WinRM للسماح برفع الاسترجاع.
لقد حاولت تمكين ذلك لفترة طويلة جدًا. جميع الأسئلة (حول مشكلات stackoverflow و reddit و github ...) أواجه نهاية في "windows isird" ، "لا أعرف ما يفعله windows هناك" ، "لم يتم توثيقه في أي مكان" ، "Windows لا يوفر هذه القدرة "،" استخدم Linux بدلاً من ذلك "،" تعطيل UAC "،" تحتاج إلى كتابة خدمة وسيط تعمل بامتيازات النظام ". لذا من فضلك إذا فهمت ذلك ، شارك معرفتك.

يمكنني فقط الإشارة إلى (1) أنه بغض النظر عن البروتوكول ، يجب أن يظل الأمان على نفس المستوى

ماذا تعني بهذا؟

مما يعني أن استرجاع SSH يجب أن يتصرف بنفس الطريقة التي يتصرف بها WinRM مع مراعاة كيفية عمل الأجزاء الداخلية من Windows

حسنًا ، لدى SSH خدمة نظام تعمل كوسيط في الخلفية للقيام بذلك بالضبط. يوفر رمز وصول إلى الشبكة ...

(2) يجب أن يعمل تنفيذ PS sudo على أي وسيلة نقل.

حسنًا ، لا يتم تجاوز WinRM لهذا السبب بالضبط. لذلك إذا كان ما قلته صحيحًا ، فنحن بحاجة إلى توثيق لكيفية تمكين استرجاع WinRM.

إذا اكتشفت ذلك ، فشارك معرفتك.

@ agowa338 طلب مني فريق MSFT عدم مناقشة الأمن علنًا وأنا أتبع مدونة السلوك. أنا أؤيد رغبتك في استكشاف هذا الموضوع بعمق ، ولكن كجزء من هذه المناقشة ، يعد هذا صداعًا لـ MSFT حول كيفية دمج هذا الحل في Windows والحفاظ على الامتثال الأمني.

حسنًا ، هذا لا يساعد أي شخص.

لاستدعاءها:

• أنت تقول أن النوافذ لديها قدرات مثل sudo داخل WinRM.
• لم يتم توثيق وجوده ولا كيفية تمكينه / تعطيله.
• الكشف عن كيفية استخدامه سيكون مخاطرة أمنية.

آسف ، ولكن هذا يبدو وكأنه باب خلفي وليس ميزة. إنه غير صالح للاستخدام لأي شخص غيرك.
كما أن الأمن من خلال الغموض لم ينجح في الماضي ...

لذلك عدنا إلى أنه لم يتم تنفيذه حاليًا ونحتاج إلى خدمة وسيط من ...

@ agowa338 لقد

كان ذلك ممكنًا ولكن تم تصحيحه في وقت سابق من هذا العام https://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/ مع التصحيح KB4480116 وأي تحديثات تراكمية لاحقة .. قبل هذا التحديث كان من الممكن رفع مستوى امتيازاتك إذا كان لديك LocalAccountTokenFilterPolicy مضبوط على 1 وهو ما يفعله winrm quickconfig (وهو مطلوب لـ WinRM حقًا).

هناك ملاحظة تفيد بأن نقاط نهاية JEA لم تتأثر ، لذا من المحتمل أن تتمكن من إنشاء PSSessionConfiguration الخاص بك والاتصال بذلك ولكنني لم أختبر هذا للتحقق. أنا شخصياً أعتقد أن هذا التصحيح سخيف لأن هذا التصحيح يوقف فقط عميل PowerShell من الاتصال بالمضيف المحلي ولكن يمكنك تجاوزه بسهولة إذا كنت تعرف ما تفعله. على سبيل المثال ، لا يزال بإمكاني الانتقال من محدود إلى مرتفع دون لمس UAC باستخدام SSH أو عميل PSRemoting آخر مثل

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 لدينا رمزًا مرتفعًا ، يمكننا أيضًا أن نرى أنه باستخدام مكتبة تابعة لجهة خارجية ، لا يزال بإمكاننا استخدام المضيف المحلي PSRemoting الذي ينشئ رمزًا مميزًا مرتفعًا وأن التصحيح ليس كتلة كاملة لهذه الوظيفة.

لا أرى أن هذا يمثل مشكلة أمنية أو عبورًا للحدود الأمنية حيث قالت MS مرارًا وتكرارًا أن التحكم في حساب المستخدم ليس حدًا أمنيًا

• 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 في التخفيف من هذه المشكلة ، لكن القيام بذلك بشكل صحيح يتطلب العمل في Windows نفسه وليس خاصًا بـ PowerShell. هناك "حلول بديلة" لكنني لن أسميها رسمية وهي مجرد نتيجة ثانوية معروفة لتمكين WinRM.

بوويرشيل

تغيير أمان Windows يؤثر على PowerShell |

تغيير أمان Windows الذي يؤثر على PowerShell 9 يناير 2019 أحدث تصحيح أمان Windows CVE-2019-0543 (1/8/2019) ، تغييرًا جذريًا لسيناريو الاتصال عن بُعد في PowerShell. إنه سيناريو ضيق النطاق يجب أن يكون له تأثير منخفض بالنسبة لمعظم المستخدمين. لا يؤثر تغيير القطع إلا على الاتصال عن بُعد بالاسترجاع المحلي ،

مدونة مارك

PsExec والتحكم في حساب المستخدم وحدود الأمان

لقد قدمت المفتاح -l إلى PsExec منذ حوالي عام ونصف كطريقة سهلة لتنفيذ العمليات مع حقوق المستخدم القياسية من حساب إداري على Windows XP. في التشغيل كمستخدم محدود - الطريقة السهلة التي وصفتها كيف تستخدم PsExec واجهة برمجة تطبيقات CreateRestrictedToken لإنشاء سياق أمني ...

نوافذ هندسية 7

تحديث على UAC

مرحبًا ، جون ديفان هنا للتحدث إليكم حول تعليقات UAC الأخيرة التي تلقيناها. يركز معظم عملنا في إنهاء Windows 7 على الاستجابة للتعليقات. ملاحظات UAC مثيرة للاهتمام بشأن بعض أبعاد عملية صنع القرار الهندسي. اعتقدت أن استكشاف هذه الأبعاد سيجعل جهاز e7 مثيرًا للاهتمام ...

iSazonov لن يؤدي أي من هذه الاقتراحات إلى رفع أمر _user-dynamic_ من _ داخل نفس جلسة وحدة التحكم _ ، خاصة في بيئة _ تفتقد UAC_. يبدو أنه يمكنك التحدث نيابة عن Microsoft في هذه الأمور ، فهل يمكنك توضيح ما إذا كانوا ببساطة غير مهتمين بتقديم مثل هذه الميزة كما وصفتها؟

إذا كان هذا هو الحال ، كما فسرت من المنشورات أعلاه ، يبدو من الحكمة إغلاق هذا الموضوع ، حيث سيتعين علينا نحن المستخدمين الآخرين البحث في مكان آخر عن حلول مثل فكرة TokenServer الخاصة بـparkovski .

يبدو أنه يمكنك التحدث نيابة عن Microsoft في هذه الأمور

أنا مشرف مجتمع للمشروع ، ولست عضوًا في MSFT ولا يمكنني التحدث نيابة عن Microsoft.

هل يمكنك توضيح ما إذا كانوا ببساطة غير مهتمين بتقديم مثل هذه الميزة كما وصفتها؟

_ جميع المقترحات لها قيمة ؛ لا أحد منهم مرفوض. المناقشة هي فقط لجمع كل المقترحات الممكنة.

أحاول حاليًا تلخيص جميع المقترحات حتى نتمكن من المضي قدمًا وليس الركود.

أن أرى.
السيناريو الرئيسي هو اعتماد مستخدمي Unix على Windows.

• من الناحية التاريخية ، يعمل مستخدمو Unix في وحدة تحكم واحدة ويساعدهم sudo أصلاً على القيام بعمل بحقوق مرتفعة في وحدة التحكم _same_
• من الناحية التاريخية ، يفتح مستخدمو Windows نافذة جديدة مع وحدة تحكم حقوق مرتفعة إذا لزم الأمر. يعمل هذا جيدًا لسنوات عديدة لأنه مناسب في بيئة متعددة النوافذ. (يمكن لمستخدمي Windows الاستفادة من pssudo أيضًا مع مراعاة Windows Core و Nano)

إذن التوقعات هي:

• pssudo يعمل فقط في الجلسات التفاعلية
• لا يفتح pssudo وحدة تحكم جديدة (نافذة UAC مقبولة على Windows ، لا نريد كسر أمان Windows وروحه)
• pssudo الاعتمادات ذاكرة التخزين المؤقت في الوقت المناسب
• pssudo لا يخزن حالة جلسة للأمان
• نفس تجربة المستخدم (قدر الإمكان) موجودة على جميع الأنظمة الأساسية
• pssudo يدير الأوامر الأصلية
• pssudo يدير كتل / ملفات البرنامج النصي PowerShell

تفاصيل التنفيذ:

• يعد الاتصال عن بُعد PowerShell هو الحل الأكثر قوة وعمليًا. تم تنفيذه بالفعل ويعمل. سيتعين على الآخرين محاكاة هذه الوظيفة أيضًا لتنفيذ كتل البرامج النصية لـ PowerShell لكل مستخدم / لكل جلسة / لكل مساحة تشغيل / لكل حالة نطاق.
• النقل المفضل هو WinRM لأن كل بنية Windows الأساسية تعتمد عليه. بعض الاستثمار مطلوب في WinRM ، على الرغم من أن MSFT لا تريد ذلك لأنه يعتمد على SOAP.
• يمكن أن يكون النقل SSH. لا يزال هذا ليس هو المعيار لنظام التشغيل Windows. يتطلب استثمارات كبيرة للتنفيذ والصيانة. وهناك مشكلة في دعم الأنظمة القديمة.
• وسائل النقل الأخرى مثل مآخذ Unix. يتطلب استثمارات كبيرة ليس فقط في البنية التحتية ولكن في PowerShell أيضًا.

@ mklement0 أتساءل أنني أفعل هنا أنك تقوم بعمل رائع عادة :-) أنت تسرقني من كوني خصمًا :-)

لماذا لا تكتب ملف windows binary يتطلب امتيازات تبدأ مثيل powerhell بأي أوامر يتم تمريرها إليه. يجب أن يكون تطبيق وضع وحدة التحكم ليعمل بشكل صحيح. ثم بالنسبة لنظام لينكس ، نكتب نصًا يتطلب أذونات تبدأ مثيل بوويرشيل بالأوامر المقدمة. إذا كان هذا يعمل من الناحية العملية كما هو الحال من الناحية النظرية ، فسيتم تشغيل بوويرشيل بأذونات مرتفعة ، وتشغيل الأوامر والمخارج.

لماذا لا تكتب ملف windows binary يتطلب امتيازات تبدأ مثيل powerhell بأي أوامر يتم تمريرها إليه. يجب أن يكون تطبيق وضع وحدة التحكم ليعمل بشكل صحيح.

لأن windows API تمنع ذلك وسيتم فتح تطبيق وحدة التحكم في نافذة جديدة. لقد تحدثنا بالفعل عن الحلول الممكنة.

شيء واحد يجب مراعاته هو أنه بغض النظر عن كيفية تنفيذ ذلك ، هناك دائمًا قفزة في العملية من وإلى عملية مرتفعة. هذا يعني أنه سيكون لديك دائمًا كائنات غير متسلسلة في خط الأنابيب وسيتم تطبيق هذه القيود. في كثير من الحالات ، لن تكون هذه مشكلة ، ولكن إذا كان الأمر cmdlet يتوقع كائن .NET مباشرًا ، فلن يعمل.

لدعم JEA مع SSH ، سنحتاج في النهاية إلى خفي / خدمة عامة تحل محل الحاجة إلى WinRM كخدمة على أي حال. في ذلك الوقت ، سنقيم استخدام ذلك لرفع جزء من خط الأنابيب.

لمعلوماتك: https://github.com/gerardog/gsudo

جيثب

جيراردوج / جسودو

سودو لنظام التشغيل Windows - قم بتشغيله مرتفعًا دون تمديد نافذة مضيف وحدة تحكم جديدة - gerardog / gsudo

لمعلوماتك: https://github.com/gerardog/gsudo

GitHub gerardog / gsudo A

حتى أفضل
http://blog.lukesampson.com/sudo-for-windows

جيثب

جيراردوج / جسودو

سودو لنظام التشغيل Windows - قم بتشغيله مرتفعًا دون تمديد نافذة مضيف وحدة تحكم جديدة - gerardog / gsudo

لوك سامبسون - سودو لنظام التشغيل Windows

سودو لنظام التشغيل Windows

حتى أفضل

لا.

لا يطالب Gsudo بكلمة المرور في كل مرة وهو أسرع في التثبيت والاستخدام.

يبدو لي أنه يجب قبول هذه المشكلة (مما يعني أنه ينبغي منحها مزيدًا من الوقت والتنظيم) بناءً على الاهتمام ليس فقط من هذه البطاقة. ليس من الصحيح عدم الاعتراف رسميًا بها كمهمة عمل حيث لن يتم حل الصعوبات الفنية المتصورة حاليًا دون مشاركة نشطة.

أنا أستخدم gsudo لبضعة أشهر الآن ولا أستطيع أن أتخيل العودة إلى نظام Windows UAC التقليدي طوال الوقت.

majkinetor تم فصل هذه المشكلة في https://github.com/PowerShell/PowerShell/issues/11343 لمزيد من المناقشة حول التصميم