5

I understand sufficiently how the ExecutionPolicy works in PowerShell. Most of what I've seen and done is how to disable it. There's even a command-line flag to disable it (powershell -ExecutionPolicy Unrestricted ...).

So my question is why, not how. Why is this even a feature? In my experience it's more of a misfeature; the only thing it's ever done for me is to annoy me, between the time I see the "cannot be loaded because the execution of scripts is disabled on this system" error, and when I remember about that -ExecutionPolicy flag.

Why would PowerShell have such a feature? It's like a burglar alarm with an on/off switch on the outside of the building next to the front door.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
William
  • 609
  • 5
  • 12
  • 1
    With PowerShell you are turning off the switch. The burglar cant. Unrestricted is also not the one that should be recommended. RemoteSigned is safer. – Matt Feb 01 '16 at 20:59
  • What stops our analogous burglar from using the same command-line switch as I can ? – William Feb 01 '16 at 21:00
  • What stops the burglar is that the burglar (or regular user) shouldn't be able to run as *Administrator* (this is the only way that you can actually change the ExecutionPolicy). The idea behind Code Signing is that you can as an Organization, only allow scripts that you have created and trusted be run. – HAL9256 Feb 01 '16 at 21:03
  • It wouldn't be PowerShell's fault at that point if someone else was executing scripts from the command line. The burglar is in with that scenario. "We traced the code. It is coming from inside the house". The point was to stop unwarrented scripts from the net to run without conscience. Most people blindly remove that restriction out of simplicity. I don't have a good explanation beyond that. – Matt Feb 01 '16 at 21:03
  • I'm not talking about (persistently) changing the execution policy, but using the ExecutionPolicy command line switch. I've tested this as a non-privileged user, and it works the same way. I can run a simple PS1 script if I use the "-ExecutionPolicy Unrestricted" command-line option, and cannot if otherwise. Why is this setting useful ? Other script interpreters I'm familiar with (bash, cmd, perl, cscript) don't have an option like that. – William Feb 01 '16 at 21:14
  • I think my point is still the same. Difference your discussing your saying is turning it off permanently or turning it off one time. It is still something the user has to do. Could just be a CYA thing for Microsoft in that it is the users decision to run code that could be potentially malicious. Someone will have a good answer. – Matt Feb 01 '16 at 21:18
  • 3
    Any answer to this question would probably be opinion-based, unless a Microsoft employee steps up to post a definitive answer. Voting to close. – Ansgar Wiechers Feb 01 '16 at 21:19
  • While my question has a rather opinionated tone, that reflects my frustration with this aspect of powershell. What I really would like to know is what the intended use-case of this feature is. I have looked, and I cannot find a statement anywhere about why/how this feature is useful. – William Feb 01 '16 at 21:26
  • 2
    There *is* some info in the docs, the description of the different available settings tells you a bit about how they expect you to deal with it - https://technet.microsoft.com/en-us/library/hh847748.aspx – sodawillow Feb 01 '16 at 21:31
  • 2
    As this [blog](https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy) opines, execution policy is not considered a security feature, but a anti-shoot-yourself-in-foot feature. This is consistent with what I've heard previously. The blog lists 15 ways to bypass the execution policy, demonstrating it's not a security feature. A use case for the command line switch I've used, is creating an app written in PS for use by non-PS savvy users. I didn't want users to have to learn about `set-executionpolicy` so I wrapped the script in a .CMD (.bat) file and used that option. – Χpẘ Feb 02 '16 at 00:09
  • See [this answer](https://stackoverflow.com/questions/49772982/) from PowerShell language designer Bruce Payette. The above comment is correct that execution policy is an administrator safety feature, not a security boundary. – Bill_Stewart Nov 10 '20 at 15:27

1 Answers1

6

Back in the dark days of ActiveX, if a user really wanted to run an ActiveX control from an untrusted source they could do so. The warnings that Internet Explorer gave were there to stop users inadvertently running malicious code not to prevent that code from ever running under any situation.

Ultimately it is the user's browser, the user's computer, and they should have control over everything it does. The browser simply says 'hey, this could be bad...'

The exact same principle is at work for PowerShell's execution policy. Once PowerShell is running it has access to all resources that the user has access to.

So why can't I, as an administrator, prevent any unsigned script from running?

Completely preventing a user from running a script would be impossible to administer, because if they have access to the PowerShell shell they can just run the commands within the script line by line.

As an administrator, by giving the user access to PowerShell, you are trusting the user to run PowerShell code. Whether in script form, or by sitting and hacking away at the PowerShell prompt.

The concept of an execution policy is a way to ensure where the script comes from. If a user has installed the appropriate certificate onto a machine, signed a script with it, then PowerShell will trust that script. PowerShell will trust the script, because the user trusts the certificate, because the certificate is in the users certificate store. If that user then runs a script that is believed to be trusted, but isn't signed by a trusted certificate it will warn the user that the script isn't trusted.

Once you get to the stage where an unauthorised process can run,

PowerShell.exe –ExecutionPolicy Bypass –File c:\temp\bad-script.ps1

You have already lost your machine. If the user runs this, then following the same principles that allowed that user to run malicious ActiveX code, they will be allowed to run malicious PowerShell scripts.

PowerShell will only warn that you're about to do something stupid. It can't stop a determined idiot.

This was mostly rewritten (stolen) from PowerShell’s Security Guiding Principles.

To wrap it around your analogy: Once the burglar has gotten past your electric fence, armed guards, and savage dogs, you might as well just let them press the button to turn the alarm off. It will save them ripping it off the wall and eating it.

Community
  • 1
  • 1
Michael B
  • 10,997
  • 4
  • 29
  • 65