Home PowerShell PowerShell ExecutionPolicy richtig verstehen!
formats

PowerShell ExecutionPolicy richtig verstehen!

PowerShell unterstützt die so genannten ExecutionPolicies, die die Sicherheitseinstellungen zur Skriptausführung auf einem System regeln sollen.

.

Mit den Cmdlets Get-ExecutionPolicy und Set-ExecutionPolicy können diese Sicherheitseinstellungen anhand von vier Ausführungsrichtlinien geregelt werden:

· Restricted (Eingeschränkt) – Es können keine Skripts ausgeführt werden. Windows PowerShell kann nur im interaktiven Modus genutzt werden.

· AllSigned (Vollständig signiert) – Nur von einem vertrauenswürdigen Autor erstellte Skripts können ausgeführt werden.

· RemoteSigned (Remote signiert) – Heruntergeladene Skripts müssen von einem vertrauenswürdigen Autor signiert werden, bevor sie ausgeführt werden können.

· Unrestricted (Uneingeschränkt) – Es gibt überhaupt keine Einschränkungen. Alle Windows PowerShell-Skripts können ausgeführt werden.

.

Der Grundzustand ist die Ausführungsrichtlinie Restricted, womit die Skriptausführung grundsätzlich verweigert wird.

Wenn man Administrator rechte hat kann man die Ausführungsrichtlinie mit dem Cmdlet Set-ExecutionPolicy verändern.
Diese Änderung gilt dann für alle Benutzer des Systems !

Die ExecutionPolicies können auch mit Group Policy Objects (GPO) gesetzt werden.

Ebenso können die ExecutionPolicies auch mit Administrator rechten über die Registry angepasst werden. Dies ist aber nicht zu empfehlen!

Nun könnte man meinen, das ist alles was man wissen muss.
Man sollte sich mit Sicherheitsfeatures immer etwas tiefer beschäftigen.
Man kann sich sonst zu schnell abgesichert fühlen.
Dies ist ebenso gefährlich, wie falsche Sicherheitseinstellungen.

Skripte sind für User immer ausführbar!

Auch wenn auf dem System die Ausführungsrichtlinien auf Restricted gesetzt ist kann jeder User trotzdem PowerShell Skripte ausführen!

Man kann ganz leicht ein PowerShell Skript mit folgender Zeile starten, obwohl das System Restricted vorschreibt:
PowerShell.exe –ExecutionPolicy Unrestricted –NoProfile –File “C:\Pfad\zum\Skript.psd1″

Eine ExecutionPolicy gilt nur für eine PowerShell Session (Sitzung).
Bei jeder neuen Sitzung die man startet kann man eine eigene ExecutionPolicy angeben, gibt man keine an wird die Einstellung übernommen die mit Set-ExecutionPolicy Systemweit gesetzt wurde.

Microsoft erklärt in einem Langen Artikel auch warum das so ist:
PowerShell’s Security Guiding Principles
http://blogs.msdn.com/b/powershell/archive/2008/09/30/powershell-s-security-guiding-principles.aspx

Dort heißt es man solle sich die ExecutionPolicies, wie bei einem Auto, als Sicherheitsgurt vorstellen.
Wenn man den Sicherheitsgurt anlegt, kann vor einem “Unfall” schützen (ungewollte Skriptausführung).

Wenn man den Sicherheitsgurt ablegt (ExecutionPolicy abschaltet) dann gibt es garkeinen Schutz mehr.

Die ExecutionPolicies sind also dafür gedacht dass man sich selbst, vor versehentlichen Aktionen schützt. (z.B. man möchte nur signierte Skripts ausführen).
Die ExecutionPolicies schützen also nicht vor (cleveren) Schadprogrammen!
Eine gesetzte Ausführungsrichtlinie muss man dann also bewusst umgehen.
Microsoft wollte hier nicht denselben “fehler” begehen wie mit dem Windows Scripting Host (WSH) und seine Visualbasic Scripts .vbs.
Diese sind und waren auch durch einen Doppelklick “versehentlich” startbar.

Microsoft erklärt auch weiterhin das eine solcher Schutz vor Schadprogrammen, gar nicht durchsetzbar ist.
Da ein User immer der Besitzer seiner Prozesse ist. Dadurch kann ein User auch seine eigenen Prozesse manipulieren, wie eben ein Schadprogramm auch!

Ebenso könnte man ein Skript auch in einen PowerShell Konsole kopieren (copy und paste) und das Skript auf diese Weise Interaktiv ausführen!

ExecutionPolicies per Code ändern

PowerShell MVP Oisin Grehan zeigt wie man mit einer .NET Methode oder einer PowerShell Funktion die ExecutionPolicy einer laufenden PowerShell sitzung im Speicher manipuliert kann.

http://www.nivot.org/nivot2/post/2012/02/10/Bypassing-Restricted-Execution-Policy-in-Code-or-in-Script.aspx

Verweise:

PowerShell’s Security Guiding Principles

http://blogs.msdn.com/b/powershell/archive/2008/09/30/powershell-s-security-guiding-principles.aspx

Bypassing Restricted Execution Policy in Code or in Script

http://www.nivot.org/nivot2/post/2012/02/10/Bypassing-Restricted-Execution-Policy-in-Code-or-in-Script.aspx

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
Kommentare deaktiviert  comments