PowerShell 7 und Windows PowerShell. Tobias Weltner

für normale Anwender. Bypass Alle Skripte sind erlaubt. Dies ist die empfohlene Einstellung für Administratoren und versierte Anwender, weil sie auch die unbeaufsichtigte Ausführung erlaubt und diese Anwendergruppe selbst entscheiden kann, ob ein Skript legitim ist oder nicht. Unrestricted Alle Skripte sind erlaubt, aber wenn die Skripte nicht lokal gespeichert sind oder aus dem Internet heruntergeladen wurden, erfolgt vor der Ausführung eine Sicherheitsabfrage. Undefined Es wird keine Festlegung vorgenommen. Die nächstniedrigere Einstellung wird zurate gezogen. Wenn alle Einstellungen auf Undefined stehen, wird die Einstellungen auf Undefined stehen, wird die Einstellung Restricted aktiviert, und die Ausführung von Skripten ist verboten. Dies ist die Grundeinstellung. Restricted Die Skriptausführung ist verboten. AllSigned Alle Skripte müssen digital signiert sein. In der Praxis wirkt diese Einstellung ähnlich wie Restricted, weil Skripte typischerweise nie signiert sind.

       Tabelle 1.1: Skriptausführungsrichtlinien

      Ob die gerade geänderte neue Einstellung auch tatsächlich wirksam geworden ist, verrät GetExecutionPolicy.

      PS> Get-ExecutionPolicy

      RemoteSigned

      Falls hier nicht die gleiche Einstellung genannt wird, die Sie gerade gesetzt haben, schauen Sie genauer nach, wer dazwischenfunkt: Es gibt nämlich mehrere Stellen, an denen diese Einstellung gesetzt werden kann:

      PS> Get-ExecutionPolicy –List

      Scope ExecutionPolicy

      ----- ---------------

      MachinePolicy Undefined

      UserPolicy Undefined

      Process Undefined

      CurrentUser RemoteSigned

      LocalMachine Undefined

      PowerShell bestimmt die effektive Einstellung, indem es die fünf Richtlinien von oben nach unten prüft. Die erste Einstellung, die nicht Undefined lautet, wird wirksam. Sind alle Einstellungen auf Undefined gesetzt, wird die Skriptausführung verboten. Das ist der Ausgangszustand der PowerShell.

      Besonderes Augenmerk verdienen die ersten beiden Richtlinien: MachinePolicy und UserPolicy werden zentral über Gruppenrichtlinien festgelegt. Sie können diese Einstellungen nicht manuell ändern. Da es die obersten beiden Einstellungen sind, haben sie Vorrang vor allen übrigen. Wenn an diesen obersten beiden Stellen also Vorgaben zu sehen sind, können Sie zwar darunter eigene Einstellungen treffen, doch werden diese niemals wirksam.

      Es ist ein Fehler – häufig auf einem Missverständnis beruhend –, wenn in MachinePolicy und/oder UserPolicy etwas anderes eingestellt ist als Undefined. In diesem Fall zwingt man die Einstellung nämlich allen Anwendern unwiderruflich auf. Stattdessen sollte man sie höchstens vorschlagen: Eine Gruppenrichtlinie sollte allenfalls einen Standardwert wie RemoteSigned für die Einstellung LocalMachine hinterlegen. Diese Einstellung würde dann für alle Anwender gelten, solange sie selbst keine andere Einstellung wählen.

      Wer die ExecutionPolicy zwingend vorschreiben will, unterliegt dem Irrglauben, es wäre ein Schutzschild gegen Angreifer. Das stimmt aber nicht. Es ist lediglich eine benutzerspezifische Präferenz, die unerfahrene Anwender schützen soll, unkritisch Skripte aus zweifelhaften Quellen zu starten. Angreifer können diese Einstellung auf mannigfaltige Weise umgehen.

       Weitere PowerShell-Einschränkungen

      In Unternehmen sollen Macht und Missbrauchspotenzial der PowerShell mitunter eingeschränkt werden. Ob Sie solchen Einschränkungen augenblicklich unterliegen, findet der folgende Befehl für Sie heraus:

      PS> $ExecutionContext.SessionState.LanguageMode

      FullLanguage

      Wenn der LanguageMode auf FullLanguage eingestellt ist, stehen Ihnen alle PowerShell-Funktionalitäten zur Verfügung. Wird hier hingegen ConstrainedMode angezeigt, wird Ihr System von Sicherheitssoftware wie Windows Defender Application Control, Software Restriction Policy, AppLocker oder einfachen Gruppenrichtlinien eingeschränkt.

      Der Hauptzweck des ConstrainedMode ist, die PowerShell auf offizielle Befehle zu beschränken und zu verhindern, dass PowerShell allzu kreativ direkt auf Systembibliotheken des .NET Framework zugreift.

      Wenn Sie mögen, können Sie eine PowerShell-Instanz testweise manuell in den eingeschränkten ConstrainedMode schalten, der dann allerdings für die gesamte weitere Laufzeit dieser Power-Shell-Sitzung gilt (also bis Sie sie schließen).

      Sobald der Modus aktiv ist, dürfen nur noch Befehle ausgeführt werden, aber keine direkten Zugriffe auf das .NET Framework:

      # PowerShell einschränken:

      PS> $ExecutionContext.SessionState.LanguageMode = "Constrained"

      # Befehle funktionieren weiterhin:

      PS> Get-Date

      Mittwoch, 16. Dezember 2020 11:50:07

      # Direkte .NET-Zugriffe sind nun verboten:

      PS> [Console]::Beep()

      InvalidOperation: Cannot invoke method. Method invocation is supported only on core types in this

      language mode.

      Welche umfangreichen Einschränkungen im ConstrainedMode und den übrigen Sprachmodi der PowerShell gelten, fasst der Artikel unter https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes zusammen.

       Achtung

      Wenn Ihre PowerShell im ConstrainedMode startet, werden viele Beispiele in diesem Buch nicht fehlerlos funktionieren, denn natürlich beschreibt dieses Buch die vollen Möglichkeiten der PowerShell und nicht bloß den kleinen Ausschnitt, den der ConstrainedMode erlaubt.

       Wichtige PowerShell-Werkzeuge

      Wirklich nötig ist für die Ausführung von PowerShell nur die Konsole, also wahlweise powershell.exe (Windows PowerShell) oder pwsh.exe (PowerShell). Damit Sie aber wirklich effektiv mit PowerShell arbeiten können, sind zumindest spezialisierte PowerShell-Editoren nötig, die Ihnen helfen, kleine und größere Skripte zu schreiben, zu testen und auszuführen.

       PowerShell-ISE-Editor

      Bei Windows PowerShell ist der spezialisierte Editor schon eingebaut: ISE (Integrated Script Environment). Er ist bei Windows also immer verfügbar, bei anderen Betriebssystemen dagegen nie, und er spricht ausschließlich Windows PowerShell.

      Sie können ihn mit dem Kurzbefehl ise in jeder Windows PowerShell-Konsole starten oder auch mit + im Ausführen-Dialog mit seinem vollen Befehlsnamen powershell_ise. Der Editor steht auch