Ausführungsrichtlinien (Execution Policy) für PowerShell-Scripts über GPO setzen

    PowerShell SecurityDie Ausführung von PowerShell-Scripts lässt sich über Richt­linien ein­schränken, standard­mäßig wird sie blockiert. Während die vom Admin interaktiv gesetzte Execution Policy von jedem User aufge­hoben werden kann, ist die Konfi­guration per GPO nach­haltiger. Sicher­heit gegen bös­willige User bietet sie aber trotz­dem nicht.

    Der wesentliche Zweck der Execution Policy besteht darin, Benutzer vor dem versehent­lichen Ausführen nicht vertrauens­würdiger Scripts schützen. Die Vor­einstellung auf einem frisch installierten Windows lautet auf Restricted, so dass kein Anwender PowerShell-Scripts starten kann, auch kein Administrator.

    Einstellungen für die Execution Policy

    Weitere mögliche Werte sind:

    • AllSigned: Nur signierte Scripts werden ausgeführt, das gilt auch für lokal erstellte.
    • RemoteSigned: Aus dem Internet herunter­geladene Scripts müssen signiert sein.
    • Unrestricted: Alle Scripts werden ausgeführt. Bei nicht signierten Scripts aus dem Internet muss man jede Ausführung am Prompt bestätigen.
    • Bypass: Keinerlei Einschränkungen, Warnungen oder Prompts.
    • Undefined: Entfernt eine zugewiesene Richtlinie

    Scope implizit auf LocalMachine

    Möchte man das voreingestellte Restricted zum Beispiel auf RemoteSigned ändern und gibt dafür den Befehl

    Set-ExecutionPolicy RemoteSigned

    ein, dann scheitert dieser, wenn man die PowerShell-Sitzung nicht mit administrativen Rechten geöffnet hat.

    User ohne administrative Rechte können die ExecutionPolicy für den Scope LocalMaschine nicht ändern.

    Der Grund dafür liegt im Gültigkeits­bereich für die Execution Policy. Gibt man den Scope nicht explizit an, dann geht Set-ExecutionPolicy von LocalMachine aus. Das würde die Einstellung für alle Benutzer auf diesem Rechner ändern, weswegen man dafür Admin-Rechte benötigt.

    PC-weite Einstellung für User überschreiben

    Wie von der Programmierung bekannt, überschreibt auch hier ein spezifischer Gültigkeits­bereich einen allgemeineren. Definiert man die ExecutionPolicy für den aktuellen Benutzer, dann überschreibt sie jene für die lokale Maschine. Daher kann jeder User eine restriktive, rechner­weite Einstellung so aufheben:

    Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

    Noch enger gefasst ist der Gültigkeits­bereich Process, der die aktuelle Sitzung betrifft. Die Einstellung dafür wird nicht wie sonst in der Registry, sondern in der Umgebungs­variable $env:PSExecution­Policy­Preference gespeichert. Sie geht nach Ende der Session verloren.

    Richtlinien für alle Scopes anzeigen

    Die Konfiguration der Execution Policy für jeden Gültigskeits­bereich kann man mit

    Get-ExecutionPolicy -List | ft -AutoSize

    anzeigen.

    Geltungsbereiche für die ExecutionPolicy von PowerShell

    Neben den oben beschriebenen Scopes LocalMachine, CurrentUser und Process erscheinen in der Ausgabe des Cmdlets noch zwei weitere, nämlich MachinePolicy und UserPolicy. Die Werte dafür lassen sich nur über Gruppen­richtlinien setzen.

    Execution Policy über GPO festlegen

    Die dafür zuständige Einstellung findet sich für die Computer- und Benutzer­konfiguration unter Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows PowerShell und heißt Skriptausführung aktivieren.

    GPO-Einstellung zur Konfiguration der Ausführungsrichtlinie von PowerShell

    Die damit konfigurierte Ausführungs­richtlinie übersteuert die interaktiv festgelegten Werte und verhindert auch, dass ein Administrator sie interaktiv ändern kann. Auch eine Umgehung durch Aufruf einer neuen Shell mit

    powershell.exe -ExecutionPolicy "Unrestricted"

    klappt dann nicht mehr, wogegen man mit dieser Technik eine Policy für LocalMachine aushebeln kann. Außer­dem ist ein Zurück­setzen auf den Wert Undefined nur durch Deaktivieren des GPO möglich.

    Über eine Gruppen­richtlinie kann man somit verbindlich vorgeben, welche Kriterien Scripts erfüllen müssen, um ablaufen zu dürfen (auf Logon-Scripts wirkt sich diese Policy übrigens nicht aus). Damit verhindert man, dass nicht vertrauens­würdige Scripts durch zu laxe Einstellungen unversehens Schaden anrichten.

    Kein Schutz gegen böswillige User

    Wenn ein Anwender entschlossen ist, diese Richtlinie zu umgehen, dann kopiert er den Inhalt eines Scripts einfach in die ISE und startet es dort. Aus dem Internet herunter­geladene, nicht signierte Scripts lassen sich trotz RemoteSigned starten, indem man die Datei mit Unblock-File freischaltet.

    Ein weiterer Bypass besteht darin, das Script in Base64 zu kodieren und über den Parameter EncodedCommand an PowerShell.exe zu übergeben. Um mögliche Schäden durch solche Aktivitäten zu begrenzen, empfiehlt sich der Einsatz des Constrained Language Mode.

    Keine Kommentare