Execution Policy on Vista or Windows Server 2008

 

Some of you may be getting an error when trying to set the execution policy on a new install of Windows PowerShell in Vista:

 PS C:/Users/leonard> Set-ExecutionPolicy unrestricted
Set-ExecutionPolicy : Access to the registry key 'HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/PowerShell/1/ShellIds/Microsoft.PowerShell' is denied.
At line:1 char:20
+ Set-ExecutionPolicy  <<<< unrestricted

This behavior is by design. As a system-wide default that affects all users, the ExecutionPolicy is stored in the HKLM registry hive. PowerShell users on XP and Windows Server 2003 likely didn't see this as most users login with administrative privileges. In Vista, this changed with the advent of User Account Control. Unless explictly requested, processes started by an Administrator account will run as a standard user and not Administrator.

The resolution here is to start PowerShell as an Administrator and then run the command. You can do this most easily by right-clicking the PowerShell icon in the Start Menu and selecting "Run as Administrator".

Why does PowerShell require administrator privileges to change the execution policy? It affects all users on the machine, and defines a safe default. It is not a user restriction, but gives a system default.

The upshot of all this is administrators can create policies where PowerShell runs signed scripts on servers and, but don't run on laptops by default. In the past, popular script malware often asked the user to go through a series of steps to execute a malicious script. ExecutionPolicy adds an additional layer of defense as it allows administrators to reduce security attack surface area and define a safe default.

As with every time I talk about security, I want to make sure I frame this in the right context: This is defense in depth and not a silver bullet. Of course it won't protect against a hacker extremely good at social engineering who can entice a user to enter commands directly into the console or prevent a sufficiently naive and determined user from being tricked into opening a text file with malware in notepad, starting PowerShell, and copying in the malicious script one line at a time. In both of these cases though, the attacker has control of the machine through the user so in practice the machine has already been effectively compromised before PowerShell was even started.