Powershell: Unterstütze sudo<powershell cmdlet=""/>

Summen! Sehr interessant. Aber ich denke, das tatsächliche Verhalten ist wie erwartet. Wie in Windows haben wir keinen Befehl wie sudo.
Sie können jedoch 'sudo Powershell' verwenden und dann die Datei foo.txt entfernen (die mit 'sudo Powershell' erstellt wurde). Dann funktioniert es, wenn Sie Remove-Item verwenden. Natürlich funktioniert es nicht mit einer nicht erhöhten Berechtigung.

Ich würde 'sudo' nur für Linux-Befehle ("sudo nautilus") in PowerShell verwenden.

:) :)

Selbst unter Windows wäre es gut, eine ähnliche Fähigkeit zu haben, ein Cmdlet wie ein anderer Benutzer oder eine erhöhte Version auszuführen, und etwas, auf das man sich in tragbaren Skripten verlassen könnte. Benötigt möglicherweise einen RFC dafür.

Diese Funktionalität wäre nützlich, um # 3506 zu umgehen.

Dies wird ein Blocker für die Anpassung von Linux für mich, wenn dies nicht behoben wird. Wir dürfen kein Sudo-Bash machen und werden auch kein Sudo-Powershell machen können.

Ich stimme Maximo zu, wir sollten sudo dem Bash überlassen und ein neues Cmdlet für die Erhöhung der Powershell erstellen, wobei sudo als Gerüst für die erwartete Funktionalität verwendet wird.

@dantraMSFT hat dies untersucht. Dan, können Sie ein Update zu aktuellen Überlegungen dazu bereitstellen?

@pixelrebirth Können Sie detaillierter
Eine beispielhafte Verwendung wäre ebenfalls nützlich.

@dantraMSFT Aus Gründen des Arguments werde ich das neue sudo-ähnliche Cmdlet nennen: Invoke-Elevated
So funktioniert sudo und würde auf Powershell-Weise in Invoke-Elevated übersetzt

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

In diesem Beispiel wird alles im Skriptblock erhöht ausgeführt und dann an ein nicht erhöhtes Get-SomeCmdlet weitergeleitet
Cred kann ein anderer Benutzer sein oder Sie selbst als Benutzer mit erhöhten Rechten (Berechtigungen müssen an einem Ort aufbewahrt werden, wie dies bei einer Sudoers-Datei oder einer Whitelist der Fall ist).

Die Protokollierung sollte standardmäßig für Fälle aktiviert sein, in denen Invoke-Elevated ausgeführt wird:
Benutzer | Befehl | DateTime oder eine ähnliche Formatprotokollierung

Vielleicht wird ein Teil davon später erweitert oder geändert, aber dies würde meine Blocker entfernen

Es sollte auch funktionieren wie:

Get-ChildItem ./test | Invoke-Elevated -command {Remove-Item -force}
Wo der Berechtigungsnachweis Ihr aktueller Benutzer ist und nur nach dem Kennwort gefragt wird ...

Get-ChildItem ist NICHT erhöht, Remove-Item ist in diesem Beispiel erhöht

Ich war heute auf dem Community-Anruf und habe danach gefragt, aber meine Frau wurde bei der Erklärung der Herausforderungen verletzt und ich habe viel davon verpasst. Können Sie bitte hier Notizen machen, damit ich sie an meinen Chef weiterleiten kann?

Ich werde jedoch nach Möglichkeit helfen und Druck ausüben, wo immer ich muss.

@ Pixelrebirth hoffe, es geht ihr gut! Wir werden in den nächsten ein oder zwei Tagen eine Aufzeichnung des Anrufs erstellen, damit Sie nachholen können, wenn Sie möchten.

Grundlegende Zusammenfassung ist, dass @dantraMSFT eine erste Untersuchung durchführt, um herauszufinden, wie dies auf nicht hackige Weise geschehen kann. Heute können Sie sudo powershell -c "invoke-foo" von einer anderen Shell aus verwenden, aber das funktioniert offensichtlich nicht.

@dantraMSFT : durcharbeiten, veröffentlichen Sie möglicherweise einen Status, um sicherzustellen, dass jeder die Kompromisse mit unterschiedlichen Ansätzen versteht.

Es mag offensichtlich erscheinen, aber vielleicht werfen Sie einen Blick auf den Sudo-Quellcode und sehen Sie, wie sie ihn verwalten - vielleicht erfordert es eine Codierung auf niedriger Ebene. Ich wünschte, ich hätte ein tieferes Code-Verständnis, um zu helfen.

Sie ist in Ordnung, sie fühlt sich auf ihrer Operationshüfte. Vielen Dank für die schnelle Antwort darauf. Ich arbeite an einer kleinen Hack-Arbeit, die ich hier posten werde, wenn ich sie durchziehe.

@pixelrebirth Als Referenz verwendet sudo das setuid-Bit. https://unix.stackexchange.com/a/80350/86669 . Es wäre wahrscheinlich eine schlechte Idee, das auf eine ganze Shell zu setzen.

Native Windows Sudo ist ein Muss (daher gehört das Problem wahrscheinlich nicht hierher, obwohl eine Option, bei der es nur über Powershell verwendet werden kann, für mich akzeptabel ist). Ich habe Powershell von Anfang an verwendet und 99 Varianten von Sudo-Skripten gesehen, wie Invoke-Elevated oben (oder meine eigene , die ich jeden Tag benutze). Das Einfügen eines solchen Cmdlets in Powershell wäre ein Fortschritt, aber alle fühlen sich im Vergleich zu Linux umständlich.

Eines der nervigen Dinge für mich ist, dass es ein neues Shell-Fenster startet (nicht unter Linux), das ich gerne in Powershell / Windows implementiert sehen würde, nicht sicher, ob dies unter Windows technisch möglich ist.

Ich mag zwar die Idee eines anderen Cmdlets ("Invoke-Elevated"), das möglicherweise in Windows verwendet werden könnte, aber ich kann nicht verstehen, warum ich PowerShell nicht mit 'sudo' öffnen soll, wenn Sie ein Skript erstellen müssen, das mit High ausgeführt werden soll Privileg?

Vor allem, wenn Sie eine Aufgabe automatisieren, deren Ausführung ohnehin mit Anmeldeinformationen mit hohen Berechtigungen geplant ist.
:) :)

Weil das nicht der typische Workflow ist. Sie "sudo" und leben dort für immer, Sie sudo-spezifische Befehle und leben in einer Nicht-sudo-Welt. In Windows gibt es keine schnelle Möglichkeit, und Powershell selbst startet nur sehr langsam, insbesondere wenn nur wenige Profilelemente enthalten sind.

In einer typischen täglichen Sitzung sudo ich 20-mal bestimmte Befehle, andere laufen unprivilegiert. Das ist der springende Punkt von sudo, Privilegien nur dann zu erheben, wenn es notwendig ist, und es könnte ziemlich oft notwendig sein.

Mein Workflow war: Befehl ausführen, er beschwert sich über Privilegien, I sudo -L die den letzten Befehl erneut mit Privilegien ausführen. Da Posh so langsam anfängt, starte ich einfach die Admin-Shell und lebe ständig darin, eindeutig keine gute Idee.

Danke @majkinetor!
:) :)

Das sudo sollte eine CLI-Variante der UAC-Eingabeaufforderung sein. Windows war bis vor kurzem noch nie CLI-freundlich, aber jetzt denke ich, dass wir das brauchen. Es ist an der Zeit, dass Sie 100% Windows-Aufgaben nur in der Shell ausführen können - ich persönlich verwende nur die Shell und den Browser, fast nichts anderes.

@majkinetor : Soweit ich weiß, ist die einzige Möglichkeit, einen erhöhten Prozess zu starten, die UAC-Eingabeaufforderung.
FWIW: Mit ShellExecuteEx können Sie dies unter Windows ohne PowerShell-Änderung erreichen.
Wenn Sie jedoch damit rechnen, die Ergebnisse zurück zu streamen; Es ist eine ganz andere Geschichte.

Soweit ich weiß, ist die einzige Möglichkeit, einen erhöhten Prozess zu starten, die UAC-Eingabeaufforderung.

Bestimmte Apps können aus der Benutzerkontensteuerung ausgeschlossen werden. Ich nehme an, dass sie die Höhe auf ihre eigene Weise handhaben.

Wollte meine Lösung / Problemumgehung für Sudo unter Windows anbieten. Jede Rückmeldung / Kritik wäre willkommen. Wenn es nicht angebracht ist, so etwas hier zu posten, entschuldige ich mich im Voraus.

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

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

Es gibt drei Funktionen im Sudo-Modul:

• New-SudoSession
• Remove-SudoSession
• Start-SudoSession

Start-SudoSession (Alias ​​"sudo") steht für einmalige Befehle, die Sie erhöhen müssen. Es fordert Sie zur Eingabe von Anmeldeinformationen auf und gibt Ihnen eine UAC-Eingabeaufforderung, bevor Sie den Befehl ausführen.

.BEISPIEL

$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 zum Öffnen einer ElevatedPSSession, in die erhöhte Befehle eingefügt werden können. Die Idee ist, dass Sie in einem längeren Skript mit mehreren Vorgängen, für die eine Erhöhung erforderlich ist, zu Beginn eine ElevatedPSSession erstellen und EINMAL eine UAC-Eingabeaufforderung erhalten und diese erhöhten Befehle dann bei Bedarf mit Invoke-Command in diese ElevatedPSSession einfügen.

.BEISPIEL

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}

Schließlich entfernt die Remove-SudoSession die von der New-SudoSession-Funktion erstellte ElevatedPSSession. Die Idee ist, dies am Ende Ihres Skripts zu platzieren. An diesem Punkt erhalten Sie eine UAC-Eingabeaufforderung. Wenn Sie also eine beliebige Anzahl von erhöhten Vorgängen in einem bestimmten Skript ausführen möchten, werden Sie nur mit zwei UAC-Eingabeaufforderungen getroffen - einer zum Öffnen einer ElevatedPSSession und einer zum Schließen. Verwendung von Remove-PSSession:

.BEISPIEL

$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

Unter der Haube wird Folgendes aus einer nicht erhöhten PowerShell-Sitzung ausgeführt (wenn die Sitzung bereits erhöht ist, wird nichts ausgeführt):

• Überprüft, ob WinRM / WSMan aktiviert und konfiguriert ist, um die CredSSP-Authentifizierung zuzulassen (wenn nicht, dann)
  Konfigurationsänderungen werden vorgenommen)

• Überprüft das lokale Gruppenrichtlinienobjekt ...

  Computerkonfiguration -> Administrative Vorlagen -> System -> Delegierung von Anmeldeinformationen -> Delegieren neuer Anmeldeinformationen zulassen

  ... um sicherzustellen, dass es aktiviert und konfiguriert ist, um Verbindungen über WSMAN / LocalHostFQDN zuzulassen

• Erstellt eine erhöhte PSSession mit dem Cmdlet New-PSSession

• Führt den Ausdruck aus, der an den Parameter -Expression in der erhöhten PSSession übergeben wird

• Entfernt die erhöhte PSSession und setzt alle Änderungen (falls vorhanden) an der lokalen Gruppenrichtlinie und der WSMAN / WinRM-Konfiguration zurück.

BEARBEITEN: Der Tippfehler "Remove-SudoSession" wurde aktualisiert.

@pldmgg Ich sehe nicht, unter welcher Lizenz sich Ihr Code befindet, daher können wir nicht einmal sehen, was Sie getan haben. Können Sie eine LIZENZ-Datei hinzufügen? MIT wäre sehr freundlich und würde uns erlauben, Ihren Code zu verwenden oder daraus abzuleiten. Vielen Dank!

@pldmgg Nach dem, was @ SteveL-MSFT erwähnt hat, ist https://choosealicense.com/ eine großartige Anleitung, die Sie bei diesem Prozess unterstützt

tl; dr - Mit den folgenden Lizenzen kann man nichts falsch machen:

• Apache 2.0
• MIT

Mehr Details

Apache 2.0 hat einige zusätzliche Stärken gegenüber MIT, aber insgesamt sind sie sehr freizügig und können problemlos mit anderen Open Source-Lizenzen verwendet werden und sind sehr geschäftsfreundlich. Wenn Sie Copyleft-Lizenzen (GPL) auswählen, kann der Code nicht mit anderen Tools verwendet werden, ohne dass diese anderen Tools zu einer GPL-Lizenz wechseln (auch als virale Lizenzierung bezeichnet). LGPL ist hier die Ausnahme, wo LGPL-lizenzierte Module / Binärdateien dies können neben anderen Tools platziert werden, ohne dass eine Lizenzänderung am anderen Code erforderlich ist).

@pldmgg auch sehr, sehr cool!

@ferventcoder Vielen Dank für die Referenz https://choosealicense.com! Wie ihr (+ @ SteveL-MSFT) wahrscheinlich vermutet habt, war ich mir nicht sicher, welche Lizenz ich wählen soll. Ich habe mein gesamtes Misc-Powershell-Repo aktualisiert, um Apache 2.0 zu verwenden, und ich habe die Datei Sudo.psd1 aktualisiert, um auf Apache 2.0 zu verweisen (in meinem Git-Repo sowie in der PowerShell-Galerie). Hoffe, dies kann für Leute von Nutzen sein! Alle Ratschläge / Kritik willkommen!

@ SteveL-MSFT Kannst du es verwenden, wenn die Lizenz Apache 2.0 ist? Wenn Sie MIT benötigen, lassen Sie es mich wissen und ich werde es aktualisieren.

@pldmgg Mein größtes Problem mit Ihrer Lösung ist die Verwendung von CredSSP. Dies ist eine weniger sichere Methode für die Verarbeitung von Anmeldeinformationen, und ich denke, sie birgt ein großes Risiko für die UAC-Grenze.

Um aus Powershell Magaize zu zitieren,

"Es ist eine schlechte Idee, CredSSP zu verwenden, um sich bei der Workstation eines Benutzers mithilfe eines Domänenadministratorkontos zu authentifizieren. Sie geben im Wesentlichen die Schlüssel an das Königreich weiter."

"Legen Sie keine Anmeldeinformationen mit hohem Vertrauen auf Computern mit geringem Vertrauen ab."

Bei der Benutzerkontensteuerung geht es darum, den Anwendungen auf dem Computer nicht zu vertrauen. Auch wenn ich einem sudo-Befehl zustimmen kann, der auf meinem Computer Chaos verursacht, verfügt er normalerweise nicht über meine Anmeldeinformationen. Wenn der Befehl sudo jetzt eindeutigen Zugriff auf meine Domänenanmeldeinformationen hat, kann er bei der Gefährdung meines Netzwerks weitaus mehr Schaden anrichten.

Kann Ihre Lösung ohne CredSSP funktionieren? Wenn nicht, welches Problem wollten Sie mit CredSSP lösen? Diese Informationen können für das PowerShell-Team hilfreich sein, um eine sicherere Lösung zu finden.

@pldmgg Ich glaube, Apache 2.0 ist ausreichend. Vielen Dank!

@ dragonwolf83 Dies ist ein häufiges Problem. Ich habe in diesem Thread tatsächlich mein ganzes Argument vorgebracht, dass es in dieser speziellen Situation in Ordnung ist:

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

Aber zusammenfassend denke ich, dass es hier in Ordnung ist, weil:

• Es wird eine Verbindung zum lokalen Host hergestellt (nicht remote).

• Seit Windows 8.1 / Server 2012R2 sendet CredSSP keine Kennwörter mehr im Klartext

• Das Remotedesktopprotokoll ist wie CredSSP immer noch anfällig für Pass-the-Hash-Angriffe. Wenn Sie sich also über CredSSP Sorgen machen, sollten Sie sich auch über RDP Sorgen machen. (Natürlich gibt es den RDP Restricted Admin-Modus oder den neuen "Credential Guard")

PS Dieser Artikel wurde für Powershell - Sicherheit meine goto Referenz werden (und es ist , wo ich über Credential Wache gelernt) .. Ich kann es sehr empfehlen.

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

Für 6.0.0 denke ich, wo wir landen werden:

Eine Skriptfunktion namens sudo, die nur unter Linux verfügbar ist (wir verschieben die Windows-Höhenunterstützung). Wenn das Argument ein Cmdlet / Scriptblock ist, wird es mit diesen Argumenten sudo Powershell. Dies bedeutet jedoch, dass Pipelining-Objekte vorerst nicht funktionieren. Wenn das Argument ein nativer Befehl ist, übergeben wir ihn einfach direkt an sudo.

Nach 6.0.0 möchten wir irgendwann eine Erfahrung machen wie:

Get-Item foo.txt | sudo Remove-Item

und lassen Sie es sowohl unter Windows als auch unter Linux funktionieren. cc @joeyaiello

Basierend auf der Diskussion von @ PowerShell / Powershell-Committee ist dies für 6.0.0 nicht erforderlich. Es wird empfohlen, in ein Cmdlet vom Typ Invoke-AsUser investieren

Um die Höhe im Allgemeinen zu ändern, benötigen Sie unter UNIX etwas mit setuid bit, und das wäre sudo selbst. sudo ist eine spezielle Binärdatei, die nicht einfach emuliert werden kann und aus Sicherheitsgründen nicht emuliert werden sollte. Bitte lassen Sie das eigentliche sudo verwendet werden, um eine temporäre Instanz von Powershell zu starten, die den betreffenden Befehl ausführt. Das Sudoing einer ganzen Shell ist auch ziemlich unsicher, wenn man bedenkt, dass man die auf einem Remote-Server geöffnete Shell möglicherweise vergisst. sudo hat einen Mechanismus, der vergisst, dass der Benutzer nach einigen Minuten erhöht hat, was die Maschine auf lange Sicht schützt. Die Lösung für dieses Problem würde es mehr Menschen ermöglichen, Powershell in der Produktion auf Linux-Servern zu verwenden. Aus heutiger Sicht wird Powershell eine Neuerung bleiben, da Sicherheit in der Produktion an erster Stelle steht.

@borgdylan Heute können Sie sudo pwsh -c foo in PowerShell Core ausführen (oder nur sudo nativecmd ). Ich denke, der Wunsch ist es, ein Cmdlet in einer vorhandenen PowerShell Core-Sitzung sudo zu können. Wir versuchen hier nicht, sudo neu zu erstellen, sondern haben etwas syntaktischen Zucker, um die Verwendung zu vereinfachen.

Angesichts der Tatsache, dass # 1527 und dieses Problem immer weiter zurückgedrängt werden, frage ich mich: Ist es wirklich so angenehm, sich bei Root-Sitzungen anzumelden, um Administratoraufgaben zu erledigen? Es gibt praktisch keine bequeme Möglichkeit, PowerShell-Befehle aufzurufen, wenn PS in irgendeiner Weise beteiligt ist.

@MathiasMagnus Ich habe dies nicht gründlich getestet, aber Sie können häufig verwendete oder wiederholt verwendete Befehle so konfigurieren, dass für sudo kein Kennwort erforderlich ist. Zum Testen habe ich dies mit visudo hinzugefügt:

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

Ich konnte dann über eine PowerShell SSH-Remoting-Sitzung sudo pwsh -c 'cat /etc/sudoers' aufrufen. Abhängig davon, wie Sie Ihre Sicherheit gewährleisten und was genau Sie in Sudoern konfigurieren (z. B. ist All=(ALL:ALL) etwas offen ...), kann dies sicher oder gefährlich sein.

Wenn Sie auf Linux ssh (dh auf Shell anstatt auf PowerShell SSH-Remoting bash), können Sie sudo mit normaler Kennwortabfrage innerhalb von pwsh ausführen, soweit ich das beurteilen kann.

Es ist nicht so sehr, dass es unmöglich ist, nur dass die aktuellen Problemumgehungen mit etwas Gepäck verbunden sind.

@MathiasMagnus # 1527 ist immer noch auf 6.1.0 ausgerichtet, da es dafür keine gute Problemumgehung gibt. Bei Cmdlets ist das Hauptproblem die Komplikation des Pipelining zu / von einem sudo'd Cmdlet. Für einzelne Operationen ist sudo pwsh -c realisierbar. Wenn jemand aus der Community eine PR einreicht, nehmen wir diese natürlich gerne entgegen.

Unter Windows ist dies jetzt ein Problem , das meines Erachtens nicht gelöst werden kann, ohne die SSH-Verbindungen nicht zu erhöhen.

Ich weiß, dass es leicht ist, über Dinge nachzudenken, die nicht funktionieren und keine Maßnahmen ergreifen, aber mein Fachwissen lag woanders. Ich trage hauptsächlich dazu bei, dass C ++ - und GPGPU-Bibliotheken und Vcpkg viele CMake-Portierungen durchführen. Ich habe noch nie C # geschrieben und glaube nicht, dass ich dazu in der Lage sein werde. Ich verwalte jedoch einen kleinen Cluster von ~ 12 Maschinen. Es ist kurz davor, von Hand verwaltet zu werden, aber die Sudo-Fähigkeit fehlt dringend, wenn ich nicht vorhabe, ein Login für den Root-Benutzer unter Ubuntu zu erstellen, was verpönt ist. DSC Core wäre eine Lösung, aber obwohl es vor einem Jahr angekündigt wurde, wurde es kürzlich auf unbestimmte Zeit verschoben.

PowerShell Core unter Linux in seiner jetzigen Form steckt zwischen der automatisierten Arbeitsweise und dem Ad-hoc-Stil, den Linux-Systemadministratoren kennen. Ich hoffe, jemand findet die Zeit, um an dieser Ausgabe teilzunehmen.

@MathiasMagnus das ist etwas, was jeder will, aber es ist kein einfaches Problem zu lösen. Beachten Sie, dass die Verwendung von sudo für native Befehle einwandfrei funktioniert. Es ist wirklich nicht verfügbar, sudo für Cmdlets auszuführen. Problemumgehung ist das Aufrufen von pwsh innerhalb von pwsh:

sudo pwsh -c etwas entfernen

Die Hauptkomplikation ist, wenn es sich um etwas innerhalb einer Pipeline handelt:

get-item foo * | sudo remove-item

@ SteveL-MSFT Zumindest ist das Konzept nicht so komplex. Bitte sag mir was du denkst.

Wir brauchen einfach eine Kombination aus den Binärdateien sudo, su und login, um alle Fälle zu behandeln.

Es muss tun:

• Erstellen Sie einen Unix-Socket für Rückrufe und erlauben Sie nur dem Zielbenutzer den Zugriff darauf.
• Überprüfen Sie, ob dem Anrufer der Sudo-Zugriff gestattet ist (ich denke, man kann einfach den Quellcode von su , sudo und login kopieren).
  
  
  
  • Wenn / etc / sudoers vorhanden ist, muss es analysiert werden
    
    
    
    
    
    • Nur bestimmte Befehle
    
    
    
    • Mit dem Passwort des Zielbenutzers
    
    
    
    • Ohne Überprüfung der Anmeldeinformationen (ohne Passwort)
    
    
    
  
  
  • Ist dies nicht der Fall, muss pem aufgerufen werden, um zu überprüfen, ob der Benutzer die Anmeldeinformationen für den Benutzer root direkt "kennt".
  
  
  • Wenn er auch die Anmeldeinformationen des Zielbenutzers nicht kennt, verweigern Sie den Zugriff und lösen Sie eine Ausnahme in Powershell aus.
  
  
• Wenn die Validierung bestanden wurde, müssen wir den Benutzerkontext entweder in root oder in den Zielbenutzer ändern.
• Sobald wir den Benutzerkontext gewechselt haben, muss der neue Prozess die Kommunikation zur ursprünglichen PowerShell wiederherstellen, indem er an den Unix-Socket angeschlossen wird.
• Wenn der Benutzer "exit" eingibt, signalisieren wir über den Unix-Socket, dass wir fertig sind, und beim Beenden kehrt der Benutzer automatisch zu den Anruferrechten zurück, sodass wir nur die Hosting-Powershell benötigen, um eine Eingabeaufforderung anzuzeigen oder die nächste auszuführen Anweisung.
• Wenn stattdessen die Host-Powershell beendet wird, wird der Unix-Socket geschlossen und die erhöhte Powershell sollte die Ausführung anhalten und beenden, genau wie wenn man das Terminal schließt.

Der Ausführungsablauf würde folgendermaßen aussehen:
PWSH (erstellt Socket /proc/self/change-user.socket) => PWSH-SU (wird mit dem Socket und dem Zielbenutzer als Parameter aufgerufen; PWSH-SU wird so eingestellt, dass es als Root selbst ausgeführt wird) => PWSH, wenn der Zielbenutzer eine Verbindung herstellt an den Unix-Socket.

Der zeitaufwändigste Teil besteht darin, der Powershell die interne Verbindung über einen Unix-Socket zu ermöglichen. Es reicht nicht aus, nur die Eingabe und Ausgabe von anderen Unix-Anwendungen umzuleiten, da wir uns beim Aufrufen von Pipes mit Objekten und nicht nur mit Zeichenfolgen befassen.

Warum alle drei Binärdateien verwenden?
sudo ist erforderlich, damit mehrere Benutzer in den Stammkontext wechseln können, ohne die
su wird verwendet, um mithilfe der Anmeldeinformationen des Zielbenutzers zu einem anderen Benutzer zu wechseln.
Mit der Anmeldung wird eine ganz neue Anmeldesitzung erstellt.
Alle diese Funktionen auch in Powershell zu haben, kann in vielen Fällen nützlich sein, verglichen mit nur einer.

Die Verwendung von Pipes könnte dazu führen, dass dies auch unter Windows auf eine Weise funktioniert, die weniger überraschend und bequemer ist. Ich hasse es, dass ich eine andere Shell mit allen "sudo" -Skripten + UAC-Klicks bekomme, aber mit Pipes wie diesen könnte dies nur innerhalb derselben Shell erfolgen Wie unter Linux, indem Sie über Pipe mit einem anderen Interpreter kommunizieren, der bereits als Administrator ausgeführt wird, und möglicherweise einige echte Sudo-Inhalte implementieren (z. B. Zeitlimit für Eingabeaufforderungen oder Sudoers-Datei mit Befehlen als Alternative zu benutzerdefinierten Powershell-Endpunkten).

Ich bin wirklich froh, die Gedanken dazu zu sehen, aber was die tatsächliche Implementierung angeht, scheinen wir uns ein wenig voraus zu sein. Das erste ist, dass das System einen Weg benötigt, um einen erhöhten Prozess zu erstellen, einen Thread, was auch immer von einem nicht erhöhten. Keines der Cmdlet-Probleme kann wirklich gelöst werden, wenn wir zunächst keine erhöhte Instanz von PowerShell erstellen können, ohne die Benutzerkontensteuerung zu durchlaufen. IMO, das erste Szenario, das hier angesprochen wird, sollte sein - Sie haben eine begrenzte SSH-Sitzung - wie führen Sie eine reguläre Exe mit Administratorrechten aus?

Ich begann mit diesem experimentieren hier (zur Zeit gebrochen , als ich habe es Refactoring, aber das Konzept funktioniert), aber ich glaube nicht , ein 3rd-Party - App die wirkliche Lösung ist. Ich würde gerne sehen, dass Windows zuerst eine "Sudo" -Exe ausliefert. Dies kann so einfach sein, dass runas aktiviert wird, um einen erhöhten Prozess mit einer Eingabeaufforderung für Anmeldeinformationen zu erstellen. Ohne den ersten Schritt ist dies alles theoretisch.

Keines der Cmdlet-Probleme kann wirklich gelöst werden, wenn wir zunächst keine erhöhte Instanz von PowerShell erstellen können, ohne die Benutzerkontensteuerung zu durchlaufen

Eine Möglichkeit, dies zu tun, besteht darin, eine geplante Aufgabe mit der Option "Mit höchster Berechtigung ausführen" zu verwenden.

Ja, aber um das zu erstellen, müssen Sie bereits über Administratorrechte verfügen, oder? Das macht psexec. Soweit ich weiß, müssen Sie jetzt irgendwann die Benutzerkontensteuerung durchlaufen. Ich würde diese Änderung gerne sehen, und da alle SSH-Sitzungen erhöht werden, ist dies eine Art Sicherheitsbedenken. Wenn eine skizzenhafte Software versucht, SSH auf meinen Windows-Computer zu übertragen, z. B. von einem anderen Computer, auf dem ich einen privaten Schlüssel eingerichtet habe (oder das Loopback-Szenario), kann sie alles tun, was sie will.

@parkovski Meine Lösung war Linux / MacOS und alle anderen * NIX-Betriebssysteme. Windows unterstützt SUID und GUID nicht.
Da sudo derzeit auch unter Windows nicht vorhanden ist, fällt es für mich nicht in den Geltungsbereich dieses Problems.

Um das UAC-Problem zu lösen, sollten Windows in Zukunft SUID und GUID implementieren. Alles andere ist nur eine schmutzige Problemumgehung für ein langjähriges Problem ...

Ja, aber um das zu erstellen, müssen Sie bereits über Administratorrechte verfügen, oder?

Richtig, aber es wird kein UAC-Popup ausgelöst.

Die Benutzerkontensteuerung kann auch offiziell mit dem Application Compatibility Toolkit von Microsoft übersprungen werden.

Windows unterstützt SUID und GUID nicht.

Windows muss dies nicht unterstützen und das Konzept ist auf diesem Betriebssystem nicht gültig.
Das Berechtigungsmodell basiert auf ACLs und es gibt keinen einzelnen Gruppenbesitz.

Es muss auch keine vollständige Sudo-Replik unter Windows sein, sondern nur eine benutzerfreundlichere Möglichkeit, Administratorbefehle aufzurufen.

Ich denke, es ist in Ordnung, die Windows-Unterstützung zu verschieben, da Windows-Benutzer wahrscheinlich daran gewöhnt sind, heute eine erhöhte PowerShell-Sitzung zu eröffnen, während Linux-Benutzer erwarten, dass sie nach Bedarf als Nicht-Root- und Sudo-Benutzer ausgeführt werden. Wir möchten nur sicherstellen, dass jedes Design die zukünftige Windows-Unterstützung nicht ausschließt. Ich würde mich wahrscheinlich auch darauf konzentrieren, sudo einfach für root zu aktivieren, anstatt dass ein beliebiger Benutzer es vereinfacht, und ich glaube, dass dies 90 +% der Nutzung ist.

@ SteveL-MSFT

Ich würde mich wahrscheinlich auch darauf konzentrieren, sudo einfach für root zu aktivieren und nicht für einen beliebigen Benutzer

Ich denke, dies wird keinen großen Unterschied machen, bietet aber die volle su / sudo-Erfahrung für die Zusammenfassung, die ich oben skizziert habe, da das Wechseln des Benutzerkontexts zu root fast das gleiche ist wie das Wechseln zu einem anderen Benutzer.

Ich denke, es ist in Ordnung, die Windows-Unterstützung zu verschieben, da Windows-Benutzer wahrscheinlich daran gewöhnt sind, heute eine erhöhte PowerShell-Sitzung zu eröffnen

Die Mehrheit der Leute, mit denen ich zusammengearbeitet habe, deaktiviert nur die Benutzerkontensteuerung, wenn sie können.

Leider ist dies in vielen Umgebungen keine Option, und ich bezweifle sehr, dass MS die Benutzerkontensteuerung vollständig verbessern wird. 😕

In diesem Problem geht es nicht um die Benutzerkontensteuerung. Aus meiner Sicht sollte es jedoch vollständig verworfen und entweder durch eine strikte Zwei-Konten-Philosophie (ein Administrator, ein Benutzer (und der Administrator kann nicht für die Anmeldung verwendet werden) ersetzt werden (die Standardinstallation zwingt Sie, diese zu erstellen) oder für die Das gleiche Konzept * NIX hat, Sie starten als Benutzer und erhöhen nach Bedarf mithilfe von sudo und SUID / SGID-Flags.

Ich habe kürzlich Folgendes zu meinem $profile hinzugefügt. Ich habe es unter https://stackoverflow.com/a/56265080/118098 ausführlicher behandelt

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

Zumindest auf den ersten Blick funktioniert das für mich und erlaubt "sudo"". Dies gilt nicht für den Fall, dass" ein Cmdlet in einer vorhandenen PowerShell Core-Sitzung sudo werden kann "( https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -354853084)

Ich frage mich jedoch, wie wichtig es ist, dem erhöhten Kontext die gesamte Sitzung des aufrufenden Befehls zu geben. In anderen Shells führt sudo den angegebenen Befehl weiterhin in einem neuen Kontext aus.

Ich habe ein grundlegendes Sudo implementiert, das sich gut zum Ausführen von Befehlen als Administrator unter Windows eignet. Ich bin mir nicht sicher, ob dies auch unter Linux / Mac funktionieren würde, da ich nicht weiß, ob "RunAs" auf diesen Plattformen korrekt angehoben wird oder nicht.

Bearbeite dein Profil:

PS > notepad $PROFILE

Fügen Sie die folgende sudo -Funktion hinzu:

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

Rufen Sie dann in Ihrer Shell auf. Unterstützt Cmdlets, ausführbare Dateien und alles, was normalerweise in eine PS-Eingabeaufforderung eingegeben werden kann:

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

Wenn Sie eine Variable oder einen Ausdruck übergeben möchten, die / der zur Laufzeit ausgewertet und nicht vorab ausgewertet wird, schließen Sie ihn in geschweifte Klammern ein. Zum Beispiel:

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

Entfernen Sie "-NoExit" aus der sudo-Funktion, wenn Sie das Administratorfenster nach Abschluss lieber schließen möchten.

@vsalvino Dies ist eine nützliche Problemumgehung, wenn die GUI verfügbar ist und in der Zwischenzeit hilfreich ist. Dies ist jedoch immer noch kein echtes Sudo, da es ohne GUI-Zugriff nicht funktioniert. In einer Remote-Shell (ssh) ist die einzige Möglichkeit, diese Funktion auszuführen, ein Dienst und ein Client, wie ich hier zu demonstrieren versuchte .

Um einige allgemeine Vorschläge anzusprechen, denn glauben Sie mir, ich habe alle Möglichkeiten geprüft:

• Das Deaktivieren der Benutzerkontensteuerung ist keine Lösung. Es ist eine Problemumgehung, die als persönliche Entscheidung getroffen werden kann, aber keine allgemeine Lösung für dieses Problem.
• Alles, was die Benutzerkontensteuerung öffnet (jedes "sudo" -Skript, das ich gesehen habe), ist keine Lösung, einschließlich der einmaligen Ausführung, um eine Remote-Sitzung mit erhöhten Rechten zu starten.
• Alles, was GUI _at all_ erfordert, ist keine Lösung. Nehmen wir an, wir verwenden hier ssh und die GUI ist nicht verfügbar.
• Alles, was größere Änderungen an Windows erfordert, ist keine Lösung. Wir können uns nicht darauf verlassen, dass aus der Benutzerkontensteuerung etwas Besseres wird.
• Selbst eine signierte Binärdatei von Microsoft ist keine Lösung, da sie nicht funktioniert, wenn die Benutzerkontensteuerung auf hoch eingestellt ist (ich habe dies in der wsudo-Readme-Datei falsch verstanden; ich werde es später korrigieren).
• Die einzige echte Lösung für sudo unter Windows ist ein Dienst, der Benutzerprozesse bei erfolgreicher Authentifizierung verbessert. Ich würde gerne andere Ideen hören, aber bitte recherchieren Sie zuerst.

Grundsätzlich wird jemand viel arbeiten müssen, um das herum nicht zu umgehen. Was wir wollen, ist etwas, das, sobald PowerShell dies unter Unix unterstützt, unter Windows weniger Ersatz bietet und so funktioniert, wie Sie es von sudo erwarten würden (keine GUI, keine Benutzerkontensteuerung).

Können wir bitte zuerst den Umfang dieses Problems klären? Ich denke, mehrere Leute sprechen gerade über verschiedene Themen.
Ist das Problem:
a) Über die Implementierung von sudo in Powershell für Linux / Mac-Systeme?
b) Implementieren Sie eine Sudo-Replik in Windows?
c) Erlauben Sie, die Berechtigungen beim Psremoting zu erhöhen?
d) Erlauben, sich unter Windows als andere Benutzer auszugeben?
e) Erlauben Sie, von einem nicht privilegierten Benutzerkonto zu einem privilegierten Benutzerkonto zu wechseln?
f) etwas ganz anderes?

Für a) https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067
Für b) Wie a (Windows hat auch Unix-Sockets), aber anstelle einer suid-Binärdatei muss sie von einem Dienst erzeugt werden (der in einem Benutzer ausgeführt wird, der über die Berechtigung "Als Teil des Betriebssystems handeln" verfügt, z. B. Benutzersystem) und Dieser Dienst muss auch die Berechtigungen überprüfen. Oder implementieren Sie das SUID / GUID-Konzept unter Windows.
Für c) nicht erforderlich haben Sie bereits die höchsten Berechtigungen beim Remoting. Beim Zugriff auf Remote-Hosts gibt es keine Trennung von Berechtigungen (es gab auch bereits einige Localhost-Loopback-UAC-Umgehungen, die auf diese Weise funktionierten).
Für d) Auch der Ansatz von a / b kann gewählt werden, aber ich weiß nicht, wie das funktionieren soll, wenn versucht wird, auf Netzwerkressourcen zuzugreifen, ohne die Anmeldeinformationen des Benutzers zu kennen oder ein neues Windows / Activedirectory-Authentifizierungs-Backend zu erstellen.
Für e) Wie b, jedoch ist auch eine Überprüfung der Anmeldeinformationen erforderlich. Alternativ kann die Runas-API gelockert werden, damit ein bekannter Benutzername und ein Kennwort ein neues Benutzertoken erhalten und die Kontrolle über diesen Prozess behalten können. (In Anbetracht der UAC-Sicherheitskonzepte und -überlegungen ist es unwahrscheinlich, dass wir wieder bei b sind.)

IMO sollte dieses Problem die Implementierung von sudo in PowerShell betreffen, wo die zugrunde liegende Funktionalität bereits vorhanden ist. Die Diskussion über ein Sudo-Äquivalent für Windows ist in dieser Terminal-Ausgabe wahrscheinlich besser geeignet.

Die Diskussion über ein Sudo-Äquivalent für Windows ist in dieser Terminal-Ausgabe wahrscheinlich besser geeignet.

Warum sollte die Terminal-App ein besserer Ort sein, um über Sudo zu diskutieren, da dies nur ein weiteres Frontend für die CLI-Welt ist? Nach der gleichen Logik können Sie ein Ticket im ConEmu-Repository ablegen.

IMO sollte dieses Problem die Implementierung von sudo in PowerShell betreffen, wo die zugrunde liegende Funktionalität bereits vorhanden ist.

Einer der Punkte der nächsten Powershell sind weniger Kompatibilitätsprobleme zwischen Systemen, die sie verwenden. In diesem Zusammenhang ist es IMO nicht akzeptabel, nur auf System X etwas zu tun.

Ich als CLI-Benutzer könnte es nicht weniger interessieren, ob sudo ausgewachsenes Linux-Sudo ist, das eine Sders-Datei oder einige Windows-Dateien verwendet. Sudo ist nur eine Schnittstelle zu den Höhenfunktionen des Betriebssystems. Eine solche Schnittstelle könnte unabhängig vom "Backend" nahezu identisch funktionieren.

Ansonsten steht @parkovski Punkt über GUI steht - ich würde nur Windows Core unter den Gründen hinzufügen, warum.

Warum sollte die Terminal-App ein besserer Ort sein, um über Sudo zu diskutieren, da dies nur ein weiteres Frontend für die CLI-Welt ist? Nach der gleichen Logik können Sie ein Ticket im ConEmu-Repository ablegen.

Weil dieses Repo nicht nur "eine Terminal-App" ist; Das Team, das es ausführt, besitzt im Grunde die Textmodus-Teile von Windows und hat bereits gesagt, dass sie daran interessiert sind, sudo zu implementieren, wenn sie die Zeit finden können. Auf der anderen Seite hat weder das PowerShell-Team noch ConEmu etwas angeboten.

Der Grund, warum ich denke, dass Windows Sudo hier nicht in den Geltungsbereich fällt, ist, dass wir bereits festgestellt haben, dass es ziemlich viel Arbeit ist, es richtig zu machen, und orthogonal zu PowerShell selbst ist. PowerShell kann es verwenden, wenn es vorhanden ist, aber es ist wirklich eine unabhängige Komponente von einer bestimmten Shell.

Auf der anderen Seite muss PowerShell Cmdlets über eine Sudo-Binärdatei ausführen können, unabhängig von der Plattform oder der tatsächlichen Funktionsweise dieser Binärdatei. Dies muss ein Teil von PowerShell sein, das genau hierher gehört.

Ich als CLI-Benutzer könnte es nicht weniger interessieren, ob sudo ein vollwertiges Linux-sudo ist, das eine Sders-Datei oder einige Fenster gleichermaßen verwendet. Sudo ist nur eine Schnittstelle zu den Höhenfunktionen des Betriebssystems. Eine solche Schnittstelle könnte unabhängig vom "Backend" nahezu identisch funktionieren.

Ja, das sollte es unbedingt. Es ist nur so, dass sudo unter Windows noch nicht existiert, viel Arbeit kostet und wahrscheinlich nicht vom PowerShell-Team geschrieben wird. Wenn so etwas existiert, hoffen wir, dass PowerShell dies so implementiert, dass es auch unter Windows funktioniert.

Wie auch immer, ich werde weitere Kommentare verschieben, bis wir hier eine offizielle Antwort erhalten, da dieses Problem in alle möglichen Richtungen geht.

Irgendeine Meinung dazu?
http://blog.lukesampson.com/sudo-for-windows
Installiert mit scoop install sudo , ist es das nächste, an das ich denken kann. Es funktioniert wie Unix-Sudo-Run-Befehle mit Elevation. Ich benutze es mit pip oder Install-Module für alle Benutzer.

Luke Sampson - Sudo für Windows

Sudo für Windows

@ Restia666Ashdoll Wenn es in Invoke-ElevatedCommand bin ich damit einverstanden .
Dies liegt daran, dass sudo nicht nur für das Erhöhen von Befehlen verantwortlich ist, sondern auch für das Identitätswechsel von Benutzern und das "Löschen" sudo -u nobody command Berechtigungen (
Ich habe oben bereits dargelegt, wie ein echtes Sudo mit Identitätswechsel aussehen würde und wie es funktionieren könnte.

@ Restia666Ashdoll Bitte lesen Sie diesen Kommentar in diesem Thread.

@parkovski Das ist nur ein Wrapper für -Verb RunAs, der nur mit wenigen Befehlen funktioniert. Der, mit dem ich verlinkt habe, kann fast mit allem verwendet werden. Zum Beispiel benutze ich es so - sudo pip install httpie .

Du hast meinen Beitrag nicht gelesen, oder?

Ich nehme nicht an, dass es eine Möglichkeit gibt, den Titel so zu bearbeiten, dass er so etwas wie "NOT A SUDO ON WINDOWS DISCUSSION" enthält. Ich weiß, dass ich persönlich nicht verpflichtet bin, darauf zu antworten, aber die Leute sagen immer wieder dasselbe, ohne ihre Nachforschungen anzustellen.

Ich habe versucht, auf den Link zum Abbestellen dieses Typen zu klicken, und das kann ich leider nicht tun, ohne als er angemeldet zu sein.

Ich habe @troymoore bereits an GitHub gemeldet

Ich möchte eine einzigartige und andere Lösung vorschlagen, über die ich hier noch nicht gesprochen habe. Was ist mit der Verwendung von Named Pipes, um Befehle an einen erhöhten Prozess zu serialisieren, der dann die serialisierte Ausgabe an den aufrufenden Prozess zurückgibt?

Hier ist ein funktionierendes Modul, das zeigt, wie dies unter NT funktionieren würde: https://github.com/mmillar-bolis/Invoke-AsAdmin

Es ist natürlich nicht perfekt, aber es erledigt einfache Aufgaben und Piplines, ohne eine andere Konsole zu öffnen. Ich habe nicht die Absicht, dies per se als sudoähnlich zu bezeichnen, da ich nicht glaube, dass das Klonen von sudos Design die beste langfristige Lösung sein wird, aber ich dachte, dass ein anderer Ansatz für dieses nebulöse Höhenproblem die konstruktive Diskussion weiter vorantreiben könnte.

EDIT: Ich sollte auch erwähnen, dass dies die Anfrage von @parkovski nach UACless Elevation nicht erfüllen wird.

Es sieht aus wie JEA.
Bei der Serialisierung unterstützen dies nicht alle Module.

Es sieht aus wie JEA.

Ja, das ist die Idee.

Bei der Serialisierung unterstützen dies nicht alle Module.

Wie Sie wahrscheinlich im Code gesehen haben, wird dies durch Textströme gemildert, die den Code am anderen Ende der Pipe rekonstruieren. Ich gebe zu, dass dies langsam ist, aber dennoch eine neuartige Problemumgehung. Ihre Erwähnung von JEA war auch hier ein einflussreicher Faktor. Wenn ein Teil des Codes nicht erhöht werden muss, sollte dies nicht der Fall sein.

Das Modul soll ein sehr spezifisches Problem lösen, bei dem interaktive Befehle in GUI-Sitzungen unter NT erhöht werden, und nicht mehr. Die Sache wurde wie vor fünf Jahren begonnen, bevor sich irgendjemand vorstellte, dass native ssh eine Sache für NT sein könnte. Ich stimme @parkovski zu, dass dies ein Problem im Zusammenhang mit der

Anstatt jedoch durch einen Nirvana-Irrtum aufgehalten zu werden, dass eine sudoähnliche Implementierung unter NT vorhanden sein muss, bevor PowerShell irgendeine Form der Befehlserhöhung unterstützen kann, warum drängen wir nicht zuerst auf irgendeine Form der interaktiven JEA-Erhebung innerhalb der Shell-Sitzung?

Dies würde zumindest eine verbesserte Sicherheitspraxis in der NT-Welt fördern. Warum nicht sowohl ein Cmdlet implementieren, um interaktiv ausgeführt zu werden, als auch eines, um eine separate Konsolensitzung zu starten? Oder noch besser, fördern Sie einfach die aktuellen Möglichkeiten, eine Sitzung mit erhöhten Rechten zusammen mit einem spartanischeren Satz von Cmdlets mit unterschiedlichen Anwendungsfällen zu starten? Es ist zumindest ein Schritt vorwärts.

Ich könnte auch hinzufügen, dass selbst die Python-Elevate-Bibliothek nicht das kann, was dieses Modul tut. Haben Sie ein anderes Modul gefunden, das noch nicht damit funktioniert? Denn mein Hauptpunkt ist, dass vielleicht klügere Köpfe als ich dieses Modul und seine Ideen nehmen und damit in eine Richtung laufen können, die für NT passt. Danach haben wir möglicherweise die Anfänge einer Plattform, auf der sich NT und * nix in der Mitte treffen können, sodass wir eine häufigere Implementierung für PowerShell überarbeiten können, um Befehle zu erhöhen.

Das sind zumindest meine zwei Cent. Aber wenn man den Code gesehen hat und das Gefühl hat, dass die darin enthaltenen Ideen nicht gut sind, werde ich verstehen. Ich hatte einfach noch niemanden gesehen, der so etwas probiert hatte.

Ich werde mich von meinen frustrierten Sorgen zurückziehen, den Punkt des Sudo für eine Minute zu erklären, weil (a) ja, dies ist ein sehr schwieriges Problem, (b) wirklich nur von MS richtig gelöst werden kann (danke, dass ich nicht Open Source bin, Windows). (c) Es ist wirklich cool zu sehen, dass andere auch davon begeistert sind.

Ich weiß, wie schwer es ist, das richtig zu machen, weil ich diesen Weg eingeschlagen habe. Wenn das einzige, was uns vorerst davon abhält, ein UAC-Dialog ist, dann sei es so. Zumindest auf diese Weise können wir mit geringem Aufwand eine plattformübergreifende Lösung testen.

Was ich persönlich von PowerShell sehen möchte, ist die umfassende Unterstützung des Unix-Sudo, die jedoch so konzipiert ist, dass sie eine Art "Pseudo-Sudo" -Skript unterstützt, wie es jetzt ist, sowie ein zukünftiges potenzielles echtes Windows-Sudo. Mein Gedanke ist, dass wenn jemand Prototypen erstellt, wie ein Windows-Sudo irgendwann funktionieren wird, aber die UAC-Einschränkung verlässt, es ziemlich einfach sein sollte, uns etwas zu geben, das im Grunde so gut ist, wie es jetzt ist, und wenn wir das echte bekommen, sollte es hübsch sein Vieles sei nur ein Ersatz.

Dies bedeutet natürlich, dass jemand ein Modell entwickeln muss, das sowohl das Unix-UID / GID-Modell als auch das Windows-Sid / Acl-Modell versteht oder zumindest übersetzt. Hoffentlich mag diese Person eine Herausforderung. Um dies zu erraten, sind auch einige Gespräche mit den Sicherheitsteams des Terminals und von Windows innerhalb von MS erforderlich.

Ich vermute, dass so viele Leute ihre eigenen Workarounds nach besten Kräften erstellt haben und dass die Unterstützung von so etwas dazu beitragen könnte, eine robuste Methode zu entwickeln, warum nicht?

Nebenbemerkung - Jeder, der diese Problemumgehungsskripte schreibt, könnte die Timeout-Funktion von sudo als ebenso ärgerlich wie dieses Popup betrachten.

Wir könnten an Start-Process pwsh -NoNewWindow -Credential $cred denken. Es funktioniert nicht, könnte aber.

Dies bedeutet natürlich, dass jemand ein Modell entwickeln muss, das sowohl das Unix-UID / GID-Modell als auch das Windows-Sid / Acl-Modell versteht oder zumindest übersetzt. Hoffentlich mag diese Person eine Herausforderung. Um dies zu erraten, sind auch einige Gespräche mit den Sicherheitsteams des Terminals und von Windows innerhalb von MS erforderlich.

Unix hat auch acls und Windows hat Posix-Kompatibilität und zumindest wenn es sich um eine Domänenverbindung handelt, gibt es auch ein primäres Gruppenattribut, das wir verwenden könnten (sowie Posix-Attribute). Es müsste nur für nicht domänenverbundene Windows-Clients implementiert werden (oder wird vorerst als User ).

Das generische Modell für Unix- und Windows-Berechtigungen lautet daher im Wesentlichen:
ACLs mit einem Eigentümer und einer Eigentümergruppe mit einigen erwarteten ACEs (Benutzer, Gruppe und andere).

Dann könnten wir die Unix-Berechtigungen wie folgt zuordnen:
uid => Eigentümer-SID
gid => Die SID der Primärgruppe des Benutzers, der das Objekt erstellt hat.
user => Creator Owner ID S-1-3-0
group => Erstellergruppen-ID S-1-3-1
andere => Welt / Jeder S-1-1-0
Das Zuordnen der UIDs aus der ACL-Liste unter Unix ist etwas komplizierter, da wir berücksichtigen müssen, dass das System Teil einer LDAP, eines Active Directory oder eines anderen Verzeichnisses sein kann. Die einzigen zwei Fälle, die ich im Rahmen von Powershell in Betracht ziehen würde, sind kein Verzeichnis und LDAP / Active Directory.
Im ersten Fall würde ich vorschlagen, S-1-6-1-uid und S-1-6-2-gid zu verwenden (vorausgesetzt, S-1-6 ist noch verfügbar und das zuständige Team ist bereit, es für diesen Zweck zuzuweisen ).
Und für den zweiten Fall brauchen wir nur eine Art Auflösung der UID durch das Authentifizierungs-Backend. Der ldap / Active Directory-Server ist dann für die Bereitstellung einer Sid verantwortlich.
Und schließlich gibt es einige Sonderfälle zu kartieren:
uid 0 => S-1-5-32-544
gid 0 => S-1-6-500 (und S-1-5-21 - * - 500)
Die meisten anderen bekannten Sids können über eine Konfigurationsdatei oder eine API verwaltet werden (oder sie einfach löschen, da sie höchstwahrscheinlich sowieso nicht verwendet werden).

Wenn wir dies in der Shell tun, würden eingebaute Befehle wie Get-Acl / Set-Acl dann auf Unix-Systemen funktionieren, ohne zu wissen, wie die Berechtigungen auf der Festplatte gespeichert sind.

@ mmillar-bolis Ich habe hier bereits einen Ansatz mit Sockets vorgeschlagen: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

Wir könnten über Start-Process pwsh -NoNewWindow -Credential $ cred nachdenken. Es funktioniert nicht, könnte aber.

Update: .Net Core (und ich denke auch die Windows-API) erlaubt es nicht, neue Prozesse auszuführen, die an dieselbe Konsole angeschlossen sind.

Wir können also nur einen erhöhten Windows-Dienst verwenden. Aber wir müssen einen solchen Serviceprozess per "sudo" erstellen, um sicher zu sein.
Die Lösung ist also New-PSSession (oder Aufruf in PSSession) für localhost mit erhöhten Benutzeranmeldeinformationen.

@iSazonov Eines der einzigen Dinge, mit denen Sie es an dieselbe Konsole anschließen können, ist das, was ich hier bereits erwähnt habe: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

Jetzt, da Windows Unix-Sockets unterstützt, können wir entweder diese oder Named Pipes verwenden. Der privilegierte Dienst ist für die Überprüfung der Anmeldeinformationen verantwortlich und muss ständig ausgeführt werden (im Vergleich zum Aufruf über suid, wie in der verknüpften Veröffentlichung für * nix oses erwähnt). .

Vielleicht müsste / könnte lsas erweitert werden, um solche Authentifizierungs-API-Funktionen bereitzustellen?
Auf diese Weise können wir uns vollständig imitieren und gleichzeitig sicher an dieselbe Konsole anschließen und Eingaben akzeptieren.

@ agowa338 Ihr Vorschlag "de facto" ist PowerShell-Remoting. Es ist bereits implementiert.

Aber

Die Lösung ist also New-PSSession (oder Aufruf in PSSession) für localhost mit erhöhten Benutzeranmeldeinformationen.

funktioniert nicht für localhost. Es wird nur AccessDenied ausgelöst.

Außer eines davon ist der Fall:

• UAC ist ausgeschaltet
• Sie versuchen, eine Verbindung zu BUILDIN \ Administrator herzustellen, ohne dass der Administratorgenehmigungsmodus aktiviert ist.
• Der Prozess (Powershell) ist bereits erhöht.

Hier ist eine gute Erklärung, warum das von @ jborean93 ist : https://github.com/PowerShell/Win32-OpenSSH/issues/1308#issuecomment -448430464

Daher benötigen wir einen privilegierten Dienst, der als Broker fungiert, oder eine der APIs muss geändert werden. Dies ist jedoch in PowerShell / PowerShell nicht möglich und muss von den Microsoft-Mitarbeitern intern delegiert werden.

@ agowa338 Der Kommentar, auf den Sie verwiesen haben, bezieht sich auf die lokale Windows-API, nicht auf PowerShell-Remoting, das dort eine Frage war.

@iSazonov : Haben Sie sogar versucht, Powershell-Remoting für localhost durchzuführen? Ich habe und es nicht aus den Gründen ,

Beim PowerShell-Remoting auf localhost können keine erhöhten Berechtigungen auf dem lokalen Computer abgerufen werden.

PowerShell-Remoting gewährt Ihnen jedoch erhöhte Berechtigungen für alle anderen Hosts im Netzwerk mit Ausnahme von localhost (vorausgesetzt, Sie sind Mitglied von Domain-Admins usw.).

Das ist der Grund, warum wir unter Windows ein Sudo-Äquivalent benötigen. Wenn sich PowerShell-Remoting so verhält, wie Sie glauben, könnte dieses Ticket geschlossen werden, indem Sie ein Beispiel in die Dokumente schreiben, da die Funktionalität bereits vorhanden wäre.

@ agowa338 Aus Sicherheitsgründen funktioniert es bei Ihnen nicht. Es ist keine Betriebssystemfunktion. Sie können WinRM wie in den Dokumenten https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooter beschrieben konfigurieren. Das Problem, auf das Sie verwiesen haben, besagt auch, dass dies für SSH funktioniert (Schritte finden Sie in diesem Artikel).

da die Funktionalität schon vorhanden wäre.

Die Anfrage ist, sich an die Arbeit zu machen "sudo Remove-Item foo.txt, wobei foo.txt im Besitz von root ist".
Es funktioniert nicht, aber wir würden wollen.
Das Problem besteht aus zwei Teilen: Syntaxzucker in Sprache und Implementierung.

Wenn Sie mehr über Ihren Vorschlag nachdenken, stellen Sie fest, dass Sie pro Benutzer / pro Sitzung / pro Runspace / pro Bereich einen Powershell-Kontext benötigen. Dann müssen Sie die Sicherheitsanforderungen erfüllen, und in der Standardkonfiguration wird "Zugriff verweigert". Danach entspricht Ihr Vorschlag dem bereits implementierten PowerShell-Remoting.

about_Remote_Troubleshooter - PowerShell

Aus Sicherheitsgründen funktioniert es bei Ihnen nicht. Es ist keine Betriebssystemfunktion. Sie können WinRM wie in den Dokumenten beschrieben konfigurieren

@iSazonov Kannst du das etwas näher erläutern? Ich kann zu diesem Computer und von jedem Computer zu jedem anderen Computer im Netzwerk remote, aber von keinem von ihnen zu localhost. Und ja, ich habe diese Seite gelesen.

Die Anfrage ist, sich an die Arbeit zu machen "sudo Remove-Item foo.txt, wobei foo.txt im Besitz von root ist".

Für Nicht-Windows-Systeme könnten wir den Unix-Socket-Ansatz verwenden, um dort Identitätswechsel / Elevation für Powershell-Remoting zu implementieren.

Können Sie das etwas näher erläutern? Ich kann zu diesem Computer und von jedem Computer zu jedem anderen Computer im Netzwerk remote, aber von keinem von ihnen zu localhost. Und ja, ich habe diese Seite gelesen.

Die meisten Angriffe zielen auf die lokale Höhe. Alle Konfigurationen sind also "standardmäßig sicher". WMI, WinRM, IIS-Loopback usw. - Alle Subsysteme deaktivieren Funktionen, die lokale Erhöhungen ermöglichen.
Es ist nicht so wichtig für die Diskussion. Selbst wenn PowerShell-Remoting es uns nicht erlaubt, standardmäßig sudo auszuführen, können wir es standardmäßig deaktiviert implementieren oder nur eine interaktive Sitzung zulassen.

Sie haben angefangen, über Windows zu sprechen. Für Nicht-Windows-Systeme könnten wir den Unix-Socket-Ansatz verwenden, um dort Identitätswechsel / Elevation für Powershell-Remoting zu implementieren.

Wir sollten für alle Plattformen die gleiche UX haben. Wirklich dort funktioniert PSRP über einen Transport - WinRM oder SSH. MSFT sagte, dass sie SSH mögen, aber ich sehe keine merklichen Fortschritte in den letzten zwei Jahren. Und es ist unglaublich, dass sie in naher Zukunft ein drittes Protokoll wollen - zu viel Arbeit (die Notwendigkeit, die Kompatibilität mit alten Systemen aufrechtzuerhalten).

Die meisten Angriffe zielen auf die lokale Höhe. Alle Konfigurationen sind also "standardmäßig sicher". WMI, WinRM, IIS-Loopback usw. - Alle Subsysteme deaktivieren Funktionen, die lokale Erhöhungen ermöglichen.
Es ist nicht so wichtig für die Diskussion. Selbst wenn PowerShell-Remoting es uns nicht erlaubt, standardmäßig sudo auszuführen, können wir es standardmäßig deaktiviert implementieren oder nur eine interaktive Sitzung zulassen.

Ich habe vor einiger Zeit versucht, dies zu aktivieren, und mir wurde wiederholt von vielen anderen gesagt, dass dies vom Betriebssystem intern eingeschränkt wird und dass dies in keiner Weise möglich ist, ohne dass eine Anwendung tief in Windows-Interna eingebunden ist. Tatsächlich haben viele auf die oben genannten Windows-API-Einschränkungen hingewiesen und diese als Argument dafür verwendet, warum Powershell niemals solche Funktionen bereitstellen könnte. Und jemand verwies sogar auf ein CVE, bei dem die Loopback-Höhe absichtlich entfernt wurde. Deshalb entschuldigen wir uns, dass wir das Kaninchenloch etwas tiefer gehen, aber was muss ich konfigurieren, damit es funktioniert? Ist das überhaupt irgendwo dokumentiert?

Wir sollten für alle Plattformen die gleiche UX haben. Wirklich dort funktioniert PSRP über einen Transport - WinRM oder SSH. MSFT sagte, dass sie SSH mögen, aber ich sehe keine merklichen Fortschritte in den letzten zwei Jahren. Und es ist unglaublich, dass sie in naher Zukunft ein drittes Protokoll wollen - zu viel Arbeit (die Notwendigkeit, die Kompatibilität mit alten Systemen aufrechtzuerhalten).

Nun, dann sollten wir beide Lösungen vorantreiben, da beide auf jeder Plattform funktionieren.

• PSRP: SSHing zu localhost funktioniert unter Windows und Linux für die Erhöhung. Daher verfügen wir unter Verwendung des psrp-Subsystems bereits über die richtigen Berechtigungen, sodass nur die Powershell-Ebene uniformiert werden muss, um das Übergeben von Objekten zu ermöglichen. Recht?
• Die Verwendung von Unix-Sockets würde auch eine ähnliche Funktionalität wie das Powershell-Remoting bieten, aber zum Zeitpunkt des Schreibens nahm ich an, dass es eine harte Einschränkung ist, eine lokale Erhöhung durchzuführen, ohne dass ein zusätzlicher Dienst als lokales System ausgeführt wird, um das Token-Swapping durchzuführen ...

Da Powershell-Remoting bereits vorhanden ist (und auch bereits über SSH funktioniert), sollten wir diese Lösung meiner Meinung nach priorisieren.

Und jemand verwies sogar auf ein CVE, bei dem die Loopback-Höhe absichtlich entfernt wurde.

Ich kann es nicht bestätigen. Ich denke, das CVE könnte Loopback standardmäßig deaktivieren, aber überhaupt nicht.
Siehe auch https://github.com/PowerShell/PowerShell/issues/3874#issuecomment -510715727

@iSazonov : Das funktioniert nicht, es stellt nur das Zugriffstoken mit niedrigen Berechtigungen bereit, nicht jedoch das Token mit erhöhtem Zugriff (z. B. Mandatory Label\High Mandatory Level ). Ich erhalte keine Administratorrechte aus einer Powershell mit geringen Berechtigungen, obwohl TrustedHosts für mich auf * ist. Das Anmeldetoken ist auch nach Enter-PSSession immer interaktiv.
Ich kann in der Tat Enter-PSSession localhost -ScriptBlock {} aber das Übergeben von Anmeldeinformationen führt zu "Zugriff verweigert". Nein, es wird immer "Zugriff verweigert" ausgegeben, wenn ein anderes System uac deaktiviert hat.

Aber ich habe es jetzt auch mit SSH versucht und das funktioniert wie erwartet, es liefert das erhöhte Token ( Mandatory Label\High Mandatory Level ) mit dem Anmeldetyp Netzwerk.

Daher können wir uns in PSCore bei der Erhöhung auf psrp verlassen (sogar lokal über Enter-PSSession -HostName localhost , was auch mit übergebenen expliziten Anmeldeinformationen funktioniert.
Wobei Enter-PSSession -ComputerName localhost -Credential $foo nicht (auch wenn $ foo.Username mit dem aktuellen Benutzer identisch ist)

@ agowa338 Ich denke, wir sollten hier nicht über die Umgehung der Sicherheitsfunktionen von WinRM sprechen (es ist ein Bereich, in dem Compliance berücksichtigt wird). Ich kann nur angeben, (1) dass die Sicherheit unabhängig von einem Protokoll auf demselben Niveau bleiben sollte, was bedeutet, dass sich SSH-Loopback genauso verhalten sollte wie bei WinRM, wenn man berücksichtigt, wie Windows-Interna funktionieren. (2) Die Implementierung von PS sudo sollte funktionieren jeder Transport.

@iSazonov : Ich habe nicht nach einem Exploit gefragt, sondern nur nach dem, was konfiguriert werden muss, um ihn zu aktivieren. Außerdem sind Sie der einzige, der herausgefunden hat, wie WinRM konfiguriert wird, um eine Loopback-Erhöhung zu ermöglichen.
Ich habe sehr lange versucht, dies zu ermöglichen. Alle Fragen (zu Stackoverflow, Reddit, Github-Problemen, ...) stoße ich auf "Windows wird wird", "Weiß nicht, was Windows dort macht", "Es ist nirgendwo dokumentiert", "Windows bietet nichts diese Funktion "," Verwenden Sie stattdessen Linux "," Deaktivieren Sie die Benutzerkontensteuerung "," Sie müssen einen Brokerdienst schreiben, der mit Systemberechtigungen ausgeführt wird ". Wenn Sie es herausgefunden haben, teilen Sie bitte Ihr Wissen mit.

Ich kann nur angeben (1), dass die Sicherheit unabhängig von einem Protokoll auf dem gleichen Niveau bleiben sollte

Was meinst du damit?

Dies bedeutet, dass sich SSH-Loopback wie WinRM verhalten sollte, wenn man berücksichtigt, wie Windows-Interna funktionieren

Nun, SSH hat einen Systemdienst, der im Hintergrund als Broker fungiert, um genau das zu tun. Es bietet ein Netzwerkzugriffstoken ...

(2) Die Implementierung von PS sudo sollte über jeden Transport hinweg funktionieren.

Nun, genau aus diesem Grund geht es nicht über WinRM. Wenn es stimmt, was Sie gesagt haben, benötigen wir eine Dokumentation zum Aktivieren von Loopback WinRM.

Wenn Sie es herausgefunden haben, teilen Sie Ihr Wissen.

@ agowa338 Das MSFT-Team hat mich gebeten, die Sicherheit nicht öffentlich zu diskutieren, und ich folge dem CoC. Ich unterstütze Ihren Wunsch, dieses Thema eingehend zu untersuchen, aber im Rahmen dieser Diskussion bereitet MSFT Kopfschmerzen, wie diese Lösung in Windows integriert und die Sicherheitsbestimmungen eingehalten werden können.

Nun, das hilft niemandem.

Um es zusammenzufassen:

• Sie sagen, Windows verfügt über sudoähnliche Funktionen in WinRM.
• Es ist weder dokumentiert, dass es existiert, noch wie es aktiviert / deaktiviert wird.
• Die Offenlegung der Verwendung wäre ein Sicherheitsrisiko.

Sorry, aber das klingt nach einer Hintertür und nicht nach einer Funktion. Es ist für niemanden außer Ihnen unbrauchbar als.
Auch Sicherheit durch Dunkelheit hat in der Vergangenheit nicht funktioniert ...

Wir sind also wieder da, dass es derzeit nicht implementiert ist und wir brauchen einen Maklerservice als ...

@ agowa338 Wir haben genügend Informationen gesammelt, damit das MSFT-Team abschließen kann. Wenn sie Sicherheitsprobleme finden, zeigen sie uns einen akzeptablen alternativen Weg.

Es war möglich, wurde aber Anfang dieses Jahres mit dem Patch KB4480116 und allen nachfolgenden kumulativen Updates gepatcht. Vor diesem Update war es möglich, eine Https://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/ Ihre Berechtigungen, wenn Sie LocalAccountTokenFilterPolicy auf 1 gesetzt haben, was winrm quickconfig tut (und für WinRM wirklich erforderlich ist).

Dort steht ein Hinweis, dass JEA-Endpunkte nicht betroffen sind, sodass Sie möglicherweise Ihre eigene PSSessionConfiguration erstellen und eine Verbindung dazu herstellen können, aber ich habe dies nicht getestet, um dies zu überprüfen. Persönlich finde ich diesen Patch albern, da dieser Patch den PowerShell-Client nur daran hindert, eine Verbindung zu localhost herzustellen, aber Sie können ihn leicht umgehen, wenn Sie wissen, was Sie tun. Zum Beispiel kann ich immer noch von eingeschränkt auf erhöht wechseln, ohne die Benutzerkontensteuerung zu berühren, indem ich SSH oder einen anderen PSRemoting-Client wie diesen verwende

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

Wir können sehen, dass wir mit SSH ein erhöhtes Token haben. Wir können auch sehen, dass wir mit einer Drittanbieter-Bibliothek weiterhin localhost PSRemoting verwenden können, das ein erhöhtes Token erstellt, und dass der Patch kein vollständiger Block dieser Funktionalität ist.

Ich sehe dies nicht als Sicherheitsproblem oder als Überschreitung einer Sicherheitsgrenze, da MS wiederholt gesagt hat, dass die Benutzerkontensteuerung keine Sicherheitsgrenze ist

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

Es mag nah sein oder sich ähnlich verhalten, ist aber nicht narrensicher. Eine dieser Möglichkeiten zur Umgehung der Benutzerkontensteuerung ist die bekannte und dokumentierte Registrierungseigenschaft LocalAccountTokenFilterPolicy . Der explizite Zweck dieser Eigenschaft besteht darin, sicherzustellen, dass die Netzwerkanmeldungen immer erhöht sind und nicht das gefilterte Token. Wenn diese Option nicht aktiviert ist, werden "Loopback" -Angriffe verhindert

Um die Benutzer, die Mitglieder der lokalen Administratorgruppe sind, besser zu schützen, implementieren wir UAC-Einschränkungen im Netzwerk. Dieser Mechanismus verhindert "Loopback" -Angriffe. Dieser Mechanismus verhindert auch, dass lokale schädliche Software mit Administratorrechten remote ausgeführt wird.

Letztendlich bedeutet dies, dass es unter Windows keine wirklich offizielle Möglichkeit gibt, Ihre Berechtigungen auf nicht interaktive Weise von einem eingeschränkten auf einen Administrator zu erhöhen. Es ist recht einfach, Start-Process ... -Verb Runas , dies erfordert jedoch eine interaktive Anmeldung, um die UAC-Eingabeaufforderung anzuzeigen. Ein sudoähnlicher Mechanismus würde helfen, dieses Problem zu lösen, aber um es richtig zu machen, müsste in Windows selbst gearbeitet werden und nicht PowerShell-spezifisch sein. Es gibt "Problemumgehungen", aber ich würde sie nicht als offiziell bezeichnen und sind nur ein bekanntes Nebenprodukt der Aktivierung von WinRM.

Power Shell

Windows-Sicherheitsänderung, die sich auf PowerShell | auswirkt

Windows-Sicherheitsänderung wirkt sich auf PowerShell aus 9. Januar 2019 Der kürzlich (08.01.2019) Windows-Sicherheitspatch CVE-2019-0543 hat eine grundlegende Änderung für ein PowerShell-Remoting-Szenario eingeführt. Es handelt sich um ein eng gefasstes Szenario, das für die meisten Benutzer nur geringe Auswirkungen haben dürfte. Die Änderung betrifft nur das lokale Loopback-Remoting.

Marks Blog

PsExec, Benutzerkontensteuerung und Sicherheitsgrenzen

Ich habe den Schalter -l vor ungefähr anderthalb Jahren in PsExec eingeführt, um auf einfache Weise Prozesse mit Standardbenutzerrechten von einem Administratorkonto unter Windows XP aus ausführen zu können. In "Als eingeschränkter Benutzer ausführen - Der einfache Weg" habe ich beschrieben, wie PsExec die CreateRestrictedToken-API verwendet, um einen Sicherheitskontext zu erstellen, der ...

Engineering Windows 7

Update auf UAC

Hallo, Jon DeVaan hier, um mit Ihnen über das jüngste UAC-Feedback zu sprechen, das wir erhalten haben. Der größte Teil unserer Arbeit bei der Fertigstellung von Windows 7 konzentriert sich darauf, auf Feedback zu reagieren. Das UAC-Feedback ist in einigen Dimensionen des technischen Entscheidungsprozesses interessant. Ich dachte, dass das Erforschen dieser Dimensionen zu einem interessanten e7 führen würde ...

@iSazonov Keiner dieser Vorschläge führt zu einer _user-interaktiven_ Befehlserhöhung von _ innerhalb derselben Konsolensitzung_, insbesondere in einer Umgebung, in der _UAC_ fehlt. Es scheint, dass Sie in diesen Angelegenheiten im Namen von Microsoft sprechen können. Würden Sie also klarstellen, ob sie einfach nicht daran interessiert sind, eine solche Funktion einzuführen, wie ich sie beschrieben habe?

Wenn dies der Fall ist, wie ich aus den obigen Beiträgen interpretiert habe, erscheint es ratsam, diesen Thread zu schließen, da der Rest von uns Benutzern anderswo nach Lösungen wie der TokenServer -Idee von suchen muss .

Es scheint, dass Sie in diesen Angelegenheiten im Namen von Microsoft sprechen können

Ich bin ein Community-Betreuer des Projekts, kein MSFT-Mitglied und kann nicht im Namen von Microsoft sprechen.

Würden Sie klarstellen, ob sie einfach nicht daran interessiert sind, eine solche Funktion einzuführen, wie ich sie beschrieben habe?

_Alle Vorschläge haben Wert; keiner von ihnen wird abgelehnt. Die Diskussion dient nur zum Sammeln aller möglichen Vorschläge.

Derzeit versuche ich, alle Vorschläge zusammenzufassen, damit wir vorankommen und nicht stagnieren können.

Dass ich sehe.
Hauptszenario ist die Einführung von Unix-Benutzern unter Windows.

• In der Vergangenheit arbeiten Unix-Benutzer in einer Konsole und helfen ihnen sudo nativ bei der Arbeit mit erhöhten Rechten in der gleichen Konsole
• In der Vergangenheit öffnen Windows-Benutzer bei Bedarf ein neues Fenster mit einer Konsole mit erhöhten Rechten. Dies funktioniert viele Jahre lang gut, da es in einer Umgebung mit mehreren Fenstern praktisch ist. (Windows-Benutzer könnten unter Berücksichtigung von Windows Core und Nano auch von pssudo profitieren.)

Die Erwartungen sind also:

• pssudo funktioniert nur in interaktiven Sitzungen
• pssudo öffnet keine neue Konsole (UAC-Fenster ist unter Windows akzeptabel, wir wollen die Sicherheit und den Geist von Windows nicht beeinträchtigen)
• pssudo rechtzeitige Cache-Anmeldeinformationen
• pssudo speichert aus Sicherheitsgründen keinen Sitzungsstatus zwischen
• Auf allen Plattformen ist (wie möglich) dieselbe UX verfügbar
• pssudo führt native Befehle aus
• pssudo führt PowerShell-Skriptblöcke / -Dateien aus

Implementierungsdetails:

• PowerShell-Remoting ist die leistungsstärkste und funktionalste Lösung. Es ist bereits implementiert und funktioniert. Andere müssten diese Funktionalität ebenfalls emulieren, um PowerShell-Skriptblöcke pro Benutzer / pro Sitzung / pro Runspace / pro Bereichsstatus auszuführen.
• Bevorzugter Transport ist WinRM, da die gesamte Windows-Infrastruktur darauf basiert. In WinRM sind einige Investitionen erforderlich, obwohl MSFT dies nicht möchte, da es auf SOAP basiert.
• SSH-Transport könnte sein. Dies ist immer noch nicht der Standard für Windows. Erfordert eine große Investition für Implementierung und Wartung. Und es gibt ein Problem bei der Unterstützung älterer Systeme.
• Andere Transporte wie Unix-Sockets. Erfordert große Investitionen nicht nur in die Infrastruktur, sondern auch in PowerShell.

@ mklement0 Ich frage mich, dass ich das hier mache, was du normalerweise großartig machst :-) Du raubst mir den Gegner :-)

Warum nicht eine Windows-Binärdatei schreiben, die Berechtigungen erfordert, die eine Powershell-Instanz mit den an sie übergebenen Befehlen startet? Es müsste eine Konsolenmodus-App sein, um richtig zu funktionieren. Dann schreiben wir für Linux ein Skript, das Berechtigungen erfordert, die eine Powershell-Instanz mit den bereitgestellten Befehlen starten. Wenn dies in der Praxis wie theoretisch funktioniert, wird Powershell mit erhöhten Berechtigungen gestartet, führt die Befehle aus und beendet das Programm.

Warum nicht eine Windows-Binärdatei schreiben, die Berechtigungen erfordert, die eine Powershell-Instanz mit den an sie übergebenen Befehlen startet? Es müsste eine Konsolenmodus-App sein, um richtig zu funktionieren.

Denn die Windows-API verhindert dies und die Konsolen-App wird in einem neuen Fenster geöffnet. Wir haben bereits über mögliche Problemumgehungen gesprochen.

Eine Sache, die Sie beachten sollten, ist, dass es unabhängig davon, wie dies implementiert wird, immer einen Prozesssprung zu und von einem erhöhten Prozess gibt. Dies bedeutet, dass Sie immer deserialisierte Objekte in der Pipeline haben und diese Einschränkungen gelten. In vielen Fällen ist dies kein Problem, aber wenn ein Cmdlet ein Live-.NET-Objekt erwartet, funktioniert es nicht.

Um JEA mit SSH zu unterstützen, benötigen wir eventuell einen allgemeinen Daemon / Service, der die Notwendigkeit von WinRM als diesen Service sowieso ersetzt. Zu diesem Zeitpunkt würden wir bewerten, ob damit ein Teil der Pipeline angehoben wird.

Zu Ihrer Information: https://github.com/gerardog/gsudo

GitHub

gerardog / gsudo

Ein Sudo für Windows - wird erhöht ausgeführt, ohne ein neues Konsolenhostfenster zu überspannen - gerardog / gsudo

Zu Ihrer Information: https://github.com/gerardog/gsudo

GitHub gerardog / gsudo Ein Sudo für Windows - erhöht ausgeführt, ohne ein neues Konsolenhostfenster zu überspannen - gerardog / gsudo

Noch besser
http://blog.lukesampson.com/sudo-for-windows

GitHub

gerardog / gsudo

Ein Sudo für Windows - wird erhöht ausgeführt, ohne ein neues Konsolenhostfenster zu überspannen - gerardog / gsudo

Luke Sampson - Sudo für Windows

Sudo für Windows

Noch besser

Nein.

Gsudo fordert nicht jedes Mal zur Eingabe eines Kennworts auf und ist deutlich schneller zu installieren und zu verwenden.

Es scheint mir, dass dieses Problem akzeptiert werden sollte (was bedeutet, dass mehr Zeit und Organisation dafür aufgewendet werden sollten), gemessen am Interesse nicht nur dieses Tickets. Es ist nicht richtig, es nicht offiziell als Arbeitsaufgabe anzuerkennen, da derzeit wahrgenommene technische Schwierigkeiten nicht ohne aktive Beteiligung gelöst werden können.

Ich benutze gsudo seit einigen Monaten und kann mir nicht vorstellen, immer wieder auf die traditionelle Windows-Benutzerkontensteuerung zurückzugreifen.

@majkinetor Dieses Problem wurde unter https://github.com/PowerShell/PowerShell/issues/11343 ausgegliedert, um weitere Diskussionen zum Design zu führen