PowerShell Execution Policies   Leave a comment

As I’ve had a number of questions on script signing, I thought I’d write a post on PowerShell Execution Policies.  What does that have to do with script signing?  Well sometimes nothing, but that’s really the point.  Sometimes we confuse signatures with execution policy.  Certificates do not allow or prevent PowerShell scripts from running.  They are used to create signatures; to sign scripts.  Signatures do not determine whether a script will run either.  They help to identify the publisher or the identity of the last modifier of the script, and to ensure that the script has not been changed since that time by some unknown entity.  Admittedly that is somewhat of a generalization, but in terms of a general understanding of what’s really going on, it’s essentially accurate.

The thing that controls whether or not PowerShell scripts will run is Execution Policy.  Depending on what the effective execution policy turns out to be, scripts and config files may or may not be allowed to run depending on whether they are downloaded from the “Internet” or not, signed or not, whether the signatures are valid, whether the certificate chains to a trusted root, and whether the certificate is from a Trusted Publisher.

Execution Policy Scopes

When determining the active execution policy, there is a precedence order as follows:

Computer Group Policy Execution Policy

  • Applies to all the computers that have this GPO setting applied to them.
  • Overrides User GPO, Session, User, and Computer Execution Policy.
  • Set only via GPO in Computer Settings.

User Group Policy Execution Policy

  • Applies only to the users that have this GPO setting applied to them.
  • Overrides Session, User, and Computer Execution Policy.
  • Set only via GPO in User Settings.

Session Execution Policy

  • Can be set by a normal user.
  • Applies only to that session, and any sessions started by that session.
  • Overrides User and Computer Execution Policy.
  • Can be set by using set-executionpolicy, or by passing the executionpolicy parameter when starting PowerShell.

User Execution Policy

  • Can be set by a normal user.
  • Applies only to that user.
  • Overrides Computer Execution Policy.
  • Can be set by using set-executionpolicy, but this is a registry setting so can be set using any method that modifies the registry.
  • HKCU\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.Powershell\ExecutionPolicy

Computer Execution Policy:

  • Can not be set by a normal user. Has to be an elevated session.
  • Applies to anyone on the computer that does not have an execution policy set in a scope with higher precedence. Can be overriden by any other scope.
  • Can be set by using set-executionpolicy, but this is a registry setting so can be set using any method that modifies the registry.
  • HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.Powershell\ExecutionPolicy

So any higher precedence policy overrides the lower precedence.  By default if no execution policy is defined for any of the above scopes, the execution policy is Restricted, and will not run any scripts.  To look at it another way, if you set a Computer Execution Policy, the only way that setting will be in affect is if you have not set a policy in any of the other scopes.

Execution Policy Values

These are the values that may be assigned to an execution policy as shown when you list the execution policies.  The value of the effective policy will determine what types of scripts can run if any.  You can list all execution policies in all scopes for the current session with the following command:

get-executionpolicy -list

Values are as follows in no particular order:

Restricted:

  • This is the default execution policy
  • No scripts can run when this is in effect.
  • Powershell commands can be run interactively.

AllSigned:

  • Scripts can run.
  • All scripts and PowerShell configuration files must be signed by a trusted publisher including locally created scripts.
  • If the signer is not trusted you’ll be prompted as to whether they should be trusted always or just this time only or not at all.

RemoteSigned:

  • Scripts can run.
  • All scripts and configuration files downloaded from the “Internet” must be signed by a trusted publisher.
  • If the signer is not trusted you’ll be prompted as to whether they should be trusted always or just this time only or not at all.
  • Locally created scripts can run regardless of whether or not they are signed.

Unrestricted:

  • Scripts can run.
  • Both locally created and “Internet” downloaded scripts and configuration files can run whether or not they are signed.
  • Will warn the user before running scripts that are downloaded from the “Internet”.

Bypass:

  • Nothing is blocked, and there are no warnings.
  • Most typically used when setting a session execution policy to allow scripts to run without any warnings as part of automated processes when no GPO based execution policies have been defined.

Undefined:

  • No execution policy set in the current scope.
  • If all scopes are “Undefined”, then the policy is Restricted.
Whats an “Internet”?

You may have noticed the quotes around the word Internet in the text above.  That’s because it may not mean what you think it means.

In general files that are downloaded or copied from an internet location, and stored on an NTFS volume, have an alternate data stream called “Zone.Identifier” added to them.  One way to see which files have alternate data streams is to use the following command:

dir /R

If you were to zip these same files up in a zip file, and then unzip them locally, the Zone.Identifier data stream is lost.  (Zip files don’t support the alternate data streams when compressing into the zip file.)  You could also copy the file to a FAT file system, and accomplish the same thing.  There are many other ways to remove the Zone.Identifier data stream, and it is even possible to take a local file and make it look like it was downloaded from the Internet.

This Zone.Identifier data stream is usually added when a browser, Windows Explorer, or Outlook download a file from different security zones and save it to a drive.  Not all browsers will track this, but IE will and various versions of Chrome and Firefox may.  In addition the configuration of IE can determine whether files copied from a UNC path are treated as “downloaded from the Internet”.

The point of all of this is that, from the perspective of PowerShell execution policies, we are not really distinguishing between files that are downloaded from the Internet or not, but between files that have the “Zone.Identifier” alternate data stream or not.  Most often, this will be fairly good indicator of whether a script file came from the Internet directly, but there are some cases such as when running from a USB key or extracted from a downloaded zip file where scripts that were technically downloaded from the Internet will appear as locally created script files.

Summing It All Up

Hopefully this helps clear up some of the confusion between the act of signing scripts and execution policies.  Scripts are signed to prove who last modified and signed the script, and to certify that it has not been modified since then.  Execution policies control whether a script can be processed or not.  Execution policies of Restricted, Unrestricted, and Bypass do not really care whether a script is signed or not.  Execution policies of AllSigned and RemoteSigned may care whether a script is signed and whether the code signing certificate is trusted.

By default PowerShell is fairly secure.  By default scripts will not run.  That does not mean PowerShell can’t be used as there is still the interactive console that can be started in any interactive logon just as they can start any other program on the system.  It is up to system administrators to determine how much to open that door of automation; under what circumstances scripts should run; and when and where those policies should be applied.

Advertisements

Posted November 9, 2011 by metzlertech in PowerShell

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: