3

I've recently discovered that by default, execution of powershell scripts is disabled. I was going to rely on it to safely remove a USB device from Windows, however if it's not enabled by default, I'd have to enable it first. Is it generally acceptable to do such things?

Alternative solutions are also welcome.

This question follows: https://superuser.com/questions/637854/safely-remove-a-usb-drive-using-bat-file/637878

Community
  • 1
  • 1
Andy
  • 3,600
  • 12
  • 53
  • 84
  • 1
    If it was "generally acceptable to do so", it wouldn't be disabled by default. You'll also need administrative privileges to enable it. – Ken White Aug 30 '13 at 15:16
  • @KenWhite Good point, so I guess I need to keep looking for an alternative now – Andy Aug 30 '13 at 15:18
  • 2
    A small caveat: that may not remain true for all Windows environments going ahead. Windows Server 2012 R2 has "RemoteSigned" as its default execution policy because, according to Jeffrey Snover, powershell scripting on Windows Server is now a "mainstream scenario." He discusses this a bit in [this video](http://www.microsoftvirtualacademy.com/Content/ViewContent.aspx?et=3447&m=3437&ct=18338#fbid=sMrXUKBssTv) around the 25 minute mark. – Anthony Neace Aug 30 '13 at 15:50

2 Answers2

3

I would not enable the execution of scripts globally on a machine just because your app wants to use it. That's an IT/Security policy decision, and they shouldn't be forced to accept your decision simply by using your software. If you're calling a PowerShell runspace from within a .NET app, you shouldn't need to worry about the execution policy since you can run your commands without calling to a separate .ps1 script. If you need to call powershell.exe and give it a script file, look at -ExecutionPolicy Bypass. About_Executionpolicies says this about Bypass:

        - Nothing is blocked and there are no warnings or
          prompts.

        - This execution policy is designed for configurations
          in which a Windows PowerShell script is built in to a
          a larger application or for configurations in which
          Windows PowerShell is the foundation for a program
          that has its own security model.
jbsmith
  • 1,616
  • 13
  • 10
  • Unfortunately it's Java, not .NET but I will bare that in mind for when I am coding in C#. Does this command line option exist in all versions of Powershell, because somewhere I read that it was only available as of V2. – Andy Aug 30 '13 at 16:33
  • That's likely, although I'm not sure. They made a lot of changes in V2. In general the PowerShell community considers V1 deprecated at this point and most people are comfortable assuming V2. – jbsmith Aug 30 '13 at 16:36
  • I think it is only available since V2, but I guess I will just have to rely on Windows Update and display an error if V2 is not available. +1 by the way – Andy Aug 30 '13 at 20:12
2

MS used to deliver systems that were 'ready-to-exploit'. They got smarter about it, and take security much more seriously. So they now disable many features by default.

As for PowerShell, the default 'execution policy' by default did not allow scripts to be run. However, on a command line you could bypass the execution policy all together (ie. without changing it) as long you have permissions to do so:

PowerShell -ExecutionPolicy Bypass -file yourfile.ps1

If you are an administrator of the machine, it's perfectly OK to enable it and use it. If you are just an app-owner, you should probably consult with the administrator to change the policy, but as noted above, you may not need to.

Adil Hindistan
  • 6,351
  • 4
  • 25
  • 28
  • 2
    I think you are reading too much into the question and into the reasons why it is disabled by default. Here is an old article from Don Jones talking about how it should be set 'in production' http://technet.microsoft.com/en-us/magazine/2007.09.powershell.aspx J. Snower, the architect himself discussed this in several occasions and explained similar reasoning. – Adil Hindistan Aug 30 '13 at 15:43
  • In a managed environment, you do not leave such decisions to 'user'. If OP is just an app owner (we dont know) then, I agree that he should consult with the administrators of the machine, but my answer is a general one to a general Q. – Adil Hindistan Aug 30 '13 at 15:49
  • I see where you are coming from but the whole premise of 'enabling/disabling' is not actually correct. I assumed people understood that, and clearly that's not the case. So, let me try to clarify my answer... – Adil Hindistan Aug 30 '13 at 16:13
  • 2
    Much better answer. I'll clean up some clutter (and rescind my vote). :-) – Ken White Aug 30 '13 at 16:52
  • Thank you for clarifying your answer. I must admit what I first read, was completely unexpected but now it makes sense. And thanks for the command line - it works. However, I am struggling to understand why there would be such an option; surely that negates the point of having such a policy? – Andy Aug 30 '13 at 20:09
  • 1
    Well, I have read different explanations on this. Some see it as a weakness (http://www.darkoperator.com/blog/2013/3/21/powershell-basics-execution-policy-and-code-signing-part-2.html) others come from the thought process of if you are on the machine with enough priviliges to change the execution context, you might as well bypass it (reminds me the discussion on Google Chrome Security head defending it to leave passwords visible to avoid false sense of security: https://news.ycombinator.com/item?id=6166731)... – Adil Hindistan Aug 30 '13 at 20:34