PowerShell Script Execution Policy

To prevent the execution of malicious scripts, PowerShell has designed something called Execution strategy (execution policy) (I prefer to call it a script execution strategy). We can set different policies in different scenarios to prevent the execution of malicious scripts. This article is mainly to explain these implementation strategies, because I learned that they are not so clear and easy to understand.
PowerShell provides six types of execution strategies for Restricted, AllSigned, remotesigned, Unrestricted, Bypass, and Undefined, which we'll cover next.

Restricted

The word Restricted means "restricted", so this execution strategy mainly restricts the execution of the script. The simple point is that you can execute a single command, but you can't execute a script. When the execution policy is Restricted, run the script and receive the following error:

Unfortunately, in Windows 8, Windows Server, and Windows 8.1 systems, Restricted is set as the default execution policy. So the first thing to do with PowerShell scripts in these environments is to tweak the execution strategy of the script. For example, set the Bypass to not limit script execution:

Set-executionpolicy-executionpolicy Bypass

Note that setting the execution policy for a script requires administrator privileges, so you need to start PowerShell with administrator privileges and then execute the commands above.

AllSigned

Signed here refers to a digitally signed script, which means that AllSigned execution policy allows all scripts with digital signatures to be executed. Of course, we can also say in a different way: only scripts with digital signatures are allowed to run. As far as I know, the vast majority of PowerShell scripts we can see are not digitally signed. If you run a script that is not signed, you will be prompted with the following error:

Next we'll figure out how to sign a PowerShell script (digitally signed)? and execute the script under AllSigned execution policy.
Signing a PowerShell script requires the use of the Set-authenticodesignature command, if you have to have a valid digital certificate. For example, I use the digital certificate file named Test.pfx. Build a Certificate object with a digital certificate file first:

$cert " test.pfx "

In general, the password is set for the certificate, so this step requires a password to be entered for verification. Then sign the Demo.ps1 script file:

" Demo.ps1 "  `     $cert "  All "  `     " Http://timestamp.verisign.com/scripts/timstamp.dll "

The last line in the middle column shows that the previous state of the file is Valid, indicating that the signature was successful. Let's take a look at what happened to the Demo.ps1 script file! To open the properties interface for the Demo.ps1 file:

More than the original "Digital Signatures" tab, here is the information of the digitally signed. Then open DEMO.PS1 to see:

In addition to the first line of script commands, many lines of comments have been added, which are all digital signatures dry.
Next we run the script Demo.ps1 under AllSigned execution policy:

The tip is that your system has not yet trusted the holder of the certificate (the author has coded the information of the certificate holder), do you want to run the script? At this point the user is required to make a judgment, if you choose "Always run", not only will execute the script, but also add the certificate to the trust list:

Is the information in Certificate Manager after selecting "Always Run", the digital certificate that I used to sign the script has been added to the trust list (the certificate information in the red box on the right). Once the digital certificate is trusted, the script signed by the digital certificate will not be prompted again!
Note: The use of digital certificates only adds a security mechanism, and in no way means that digitally signed scripts must be secure and reliable. A domestic certification authority because there is no bottom line hair certificate by Google, Firefox and other products to remove the trust list. Now that a certification authority exists, someone will take the opportunity to purchase a digital certificate and sign a malicious script, so it is not possible to differentiate whether a script is trustworthy by a digital signature alone.

remotesigned

Starting with Windows Server R2, the default execution policy in PowerShell was changed to remotesigned. This execution strategy means that when you execute a script that is downloaded from the network, the script needs to be digitally signed, or the script will not run. If the script is created locally, it can be executed directly without requiring the script to have a digital signature.
So the question is, how does PowerShell know if the script was created locally or downloaded from the network?
Originally, in the Windows-provided API, there is an enumeration that identifies the source of the file.

 Public enum securityzone{    =-1,    0,    1,     2 ,     3 ,     4 ,}

When a tool such as a browser or Outlook downloads a file from the network, the value of this enumeration should be updated by the Windows system-provided API. Let's download a PowerShell text from the Web (which can actually be any file) with the file name 0start.ps1 and right-click to open the Properties interface:

The content in the red box is the description of the related property. We can also display its properties as text in Notepad using the following command:

This is clearly shown here, and zoneid=3 indicates that the file was downloaded from the Web.

Unrestricted

This is a more tolerant strategy that allows unsigned scripts to be run. For scripts downloaded from the network, security prompts are made before running:

But this is only a hint, or allows the script to execute.

Bypass

Bypass execution policy does not impose any restrictions on the execution of scripts, and any script can be executed without a security hint.

Undefined

Undefined indicates that no scripting policy has been set. Of course, inheriting or applying the default scripting policy occurs at this point.

Execution Policy Scope

Scope refers to the scope of application of the execution strategy. It turns out that we can set execution policies for different application scopes. such as processes, current users, and native.
The Get-executionpolicy and Set-executionpolicy commands default to the native script execution policy. If you want to get the execution policy for the current user, you can use the-scope option:

Get-executionpolicy-scope CurrentUser

Similarly, if you modify only the execution policy of the current user, you can use the scope parameter in the Set-executionpolicy command.

Set-executionpolicy-executionpolicy <PolicyName>-scope CurrentUser

Summary

It is clear that PowerShell has carefully designed the execution strategy of the script. Unfortunately, in Windows 8, Windows Server, and Windows 8.1 systems, Restricted is set as the default execution policy. This makes it somewhat overwhelming for the novice to learn about PowerShell, because everyone will encounter a problem that cannot be executed the first time the script is executed. Fortunately, MS has changed the default execution strategy to remotesigned in the new system, at least more friendly to novices.

PowerShell Script Execution Policy