So firstly, what are PowerShell execution policies?
Well, PowerShell execution policies serve three specific purposes.
The first one is they are a safety feature to control the conditions
that a PowerShell script can actually execute.
They also prevent execution,
or at least try to prevent execution of malicious scripts.
And then, of course,
you can scope the execution of those scripts to specific PowerShell sessions.
So just because we set a blanket policy that says scripts can be executed,
we can actually tie that down a little bit more.
Execution policies for the local computer,
so if you're on a Windows machine and the current user,
are stored inside the registry, so when we execute the PowerShell command,
it will change a flag in the registry to say,
going forward, this is the value.
The execution policy itself isn't necessarily a security system.
It won't stop specific types of actions from taking place.
It's just either to allow specific types of execution,
but it won't stop, you know, someone who has full access
from executing even malicious code.
On a Windows computer,
you can set the execution policy for either the local computer itself,
for the currently logged‑in user,
or for a particular PowerShell session that you may be in.
For non‑Windows computers, it's always set to unrestricted,
and there's no way of changing that.
And that's purely based on the fact that it doesn't
necessarily run all of the same objects,
there's no .NET Framework, for example, there's no Windows components,
there's no registry.
So for non‑Windows it's always unrestricted,
which means we can basically execute whatever we need to.
The most important thing here is to understand that enforcement
of policies only occurs on Windows platforms.
There's no way of enforcement on anything else at the moment.
So what are the PowerShell execution policies that are available to us?
Well, there were five of them that are the main ones that we would utilize.
The first one is AllSigned,
which means it will execute any of the scripts that have
been signed with an SSL certificate.
Bypass means it just doesn't do anything.
It just ignores any of the policies and will let you do whatever is needed.
We then have remotely signed, which is kind of like the AllSigned.
We then have the two most common,
which would be Restricted and Unrestricted. Restricted means it's
going to block and potentially not allow scripts to execute.
Unrestricted means that you can just go ahead and execute
whichever script is sent to you.
So if I create a PS1 file with a bunch of code in it,
you could just run it with no questions whatsoever.
So let's talk about each one of these.
First off, let's talk about the AllSigned policy.
This allows scripts to be executed.
Now, it does require that all the scripts and the
configuration files are signed by a trusted publisher.
So, for example,
you've seen components on a Windows machine that are
signed by Microsoft certificates.
It would need to be along those similar lines.
It will prompt you before you run the scripts for anything that
isn't classified as trusted or untrusted, so you have to go
through an exercise to say this is trusted.
However,
there is a risk here of allowing malicious scripts
that have been signed to be executed.
So this is going to be a common thing across each of the
types of execution policies, that there is really no way to
truly block malicious scripts.
That's really down to you having to look at the scripts and
determine whether you wish to execute them or not.
Our next one is the Bypass policy.
This basically just says nothing is blocked, and there's no warnings,
no prompts.
You can basically do whatever you need to.
The execution policy is designed,
really, not for end users or admins. It's designed for
configurations in which the PowerShell script is kind of
what's making the program work.
So, for example,
you may have known in years past that things like Exchange
Server, when they built new versions of Exchange,
they actually built the PowerShell layer first and then
wrote the user interface over the top.
So we're kind of talking about something that heavily requires on a
PowerShell script to run and doesn't necessarily require you as an
admin or an end user to actually do anything.
Also,
for applications that have their own security models but utilize PowerShell,
this is the perfect option.
But this should not be a choice that's given to regular
users. So the next policy is RemoteSigned.
This allows execution of scripts, as always. It does
require a digital signature from a trusted publisher, so
very much like the AllSigned policy.
It doesn't require a digital signature on anything that you write locally.
So if you create your own PS1 file, and you want to
execute it on a Windows machine,
that's perfectly fine and there's no need for any signatures to be assigned.
It will run scripts that are not signed if those scripts
have been unblocked. So obviously by default it is going to
block some of those scripts.
There is also the risk of running unsigned scripts and
signed scripts that could be malicious.
So like I mentioned before, there's still no magical way of saying,
don't run or execute that malicious code.
Our next one is Restricted policy.
This is the default execution policy for Windows client computers.
So by default it's going to block those scripts from being executed.
It will permit individual commands.
So, for example, you could say Get‑ComputerInfo,
for example, but it won't allow you to run a full
script that you may have written.
It will also prevent running of all script files,
so you'll need to either determine a different policy or if that's
the policy you're going to apply, then maybe you need to look at a
session‑based policy instead. Then lastly,
we have Unrestricted policy.
So an Unrestricted policy is the default policy for non‑Windows computers, so,
for example, like a Mac or something else. Unsigned scripts can execute.
There's a massive risk of running malicious scripts
because it'll basically execute anything.
It will warn the user before running scripts and configuration files
that are not technically classed as local internet zone, kind of like
the browser. But for all intents and purposes, it will execute whatever is needed.