Q: Does Windows include a security mechanism that controls what PowerShell scripts are allowed to run on a Windows box?
A: Yes, you can control what PowerShell scripts can run on a Windows system using execution policies. Microsoft created four PowerShell execution policies to help administrators follow basic scripting security rules and prevent them from unintentionally violating these rules. PowerShell's predecessor—Windows Script Host (WSH)—had no such mechanism.
Before I discuss the four execution policies, it's important to point out that they aren't an all-restricting security mechanism. Users can still easily circumvent them. For example, one way to do so is to type a script's contents on the command line. For a list of execution policy bypass mechanisms, see the NetSPI blog post "15 Ways to Bypass the PowerShell Execution Policy."
PowerShell's four execution policies are:
- Restricted. This default execution policy applies to all Windows versions, with the exception of Windows Server 2012 R2. Restricted is the most secure policy because it allows PowerShell to operate only in an interactive mode. This means that you can only run individual commands. You can't run scripts under this policy, regardless of where the scripts came from (local or downloaded) and whether they're signed.
- AllSigned. The AllSigned policy allows scripts to be run as long as they've been digitally signed by a trusted publisher. With this policy, when you attempt to run a signed script, you'll receive a prompt asking you to confirm that you trust the publisher.
- RemoteSigned. The RemoteSigned policy allows scripts to be run but requires that downloaded scripts have a digital signature from a trusted publisher. Scripts that you run from the local computer don't need to be signed. Under this policy, there are no prompts when you attempt to run a script. RemoteSigned is the default execution policy in Server 2012 R2.
- Unrestricted. The Unrestricted policy allows all scripts to be run, regardless of whether they're signed and where they come from.
Each execution policy can be applied to different scopes to control exactly who is affected by the policy. PowerShell supports five execution policy scopes:
- MachinePolicy. When the MachinePolicy scope is set, the execution policy applies to all users on a machine. You must use a Group Policy Object (GPO) to apply an execution policy with this scope.
- UserPolicy. When the UserPolicy scope is set, the execution policy applies to the current user. You must use a GPO to apply an execution policy with this scope.
- Process. When the Process scope is set, the execution policy applies to the current PowerShell process. When an execution policy has this scope, the policy is stored in a PowerShell session environment variable that's deleted when the session is closed.
- CurrentUser. When the CurrentUser scope is set, the execution policy applies to the current user. When an execution policy has this scope, the policy is stored in the HKEY_CURRENT_USER registry container.
- LocalMachine. When the LocalMachine scope is set, the execution policy applies to all users. When an execution policy has this scope, the policy is stored in the HKEY_CURRENT_MACHINE registry container.
The scope values are listed in precedence order (from high to low). The policy that takes precedence is the one that is effective in the current PowerShell session, even if a more restrictive policy is set at a lower level of precedence. For example, if you have a RemoteSigned policy with the CurrentUser scope and an AllSigned policy with the LocalMachine scope, RemoteSigned will be the effective policy because it has a higher precedence.