Search
Joe Pruitt - A Software Architect's take on Network Security
You are here: DevCentral > Weblogs

posted on Thursday, December 18, 2008 1:02 PM

PowerShell_2 Welcome to this addition of the PowerShell ABC's where you'll find 26 posts detailing a component of the PowerShell scripting language, one letter at a time.  Today's letter is the letter "E".  For "E" I've picked the word that relates to how PowerShell's security model supports execution of scripts.  Today's word is ExecutionPolicy.

One of the main features of PowerShell is the ability to execute scripts.  But, scripts are not inherently "safe" and since PowerShell has no concept of sandboxing, the execution of scripts are disabled by default.  The default way to execute scripts is via the console interpreter.

But, since PowerShell's function is to execute scripts, there has to be a way to enable it in your environment.  The way to configure this is with the PowerShell Execution Policy.  The execution policy is stored in the registry and there are two handy Cmdlet's to get and set it's values.

Get-ExecutionPolicy
Set-ExecutionPolicy [-executionPolicy] {<Unrestricted> | <RemoteSigned> | <AllSigned> | <Restricted>}

The descriptions for the execution policies are as follows:

Restricted

This is the default execution policy.  When this policy is set, script execution is completely disabled.  PowerShell can still be used to interactively interpret commands. While this is the default policy, it severely limits the user of PowerShell for automation.

policypenAllSigned

When the execution policy is AllSigned, scripts can be executed, but only if they have been digitally signed.  When running a signed script, you will be asked if you trust the signer of the script before it will execute.  This is still a secure policy, but it makes script development difficult.  This is best suited for environments where scripts are to be deployed rather than created.

RemoteSigned

RemoteSigned means that all scripts that are downloaded from a remote location must be digitally signed before they can be executed.  This depends on the application downloading the script to mark it as coming from a remote location.   Anything downloaded with Internet Explorer, Outlook, or Outlook Express will be properly marked.  This is the minimum recommended execution policy setting and is the best setting for script development.

Unrestricted

When the execution policy is unrestricted, PowerShell will run any and all scripts you give it.  It will still prompt the user when it encounters a script that has been downloaded however.  This is the least secure setting and is not recommended that you use this setting, but it may be necessary in some developer scenarios where RemoteSigned is too restrictive.

For more information on signing PowerShell scripts, see Scott Hanselman's excellent post on the topic.



Feedback

7/19/2010 7:24 PM
Gravatar Can you read the articles. To my great help.
uggs sale online

Let Me Know What You Think


Please use the form below if you have any comments, questions, or suggestions.

Title:
 
Name:
 
Email: (so we can show your gravatar)
Website:
Comment: Allowed tags: blockquote, a, strong, em, p, u, strike, super, sub, code
 
Please add 2 and 4 and type the answer here:

Blog Stats

Posts:379
Comments:1067
Stories:1
Trackbacks:301
  

Article Categories

  iRules
  

Image Galleries

  

Joe's bookshelf: read

The Lost Gate
4 of 5 stars
This one started slow but I got really got into it about 1/3 of the way through. If you are an Ender's Game fan, you'll probably like this one as well.

goodreads.com


82,243 Members in 102 Countries and Growing!

Join DevCentral Today!

About DevCentral

DevCentral has been a successful, thriving community for many years. We have always strived to bring you the best technical documentation, discussion forums, blogs, media and much more that we can.

So dive in, get familiar with DevCentral. We hope you like it, we hope it makes your job easier, and lets you get that much more power out of the community. To learn more, make sure to check out the Getting Started section. And if you have any problems, or think something could be easier to use, drop us a line to let us know.

Got It !

We've received your comment and transmitted it directly to DevCentral HQ.

Thanks for taking time to let us know what's on your mind. At DevCentral | Community Matters!

Get In Touch With Us

Have questions, suggestions or just want to get something off your chest?

Use our handy form below to Direct Connect with DevCentral Mission Control.

Send Us Feedback       or