4 ms·

This is obviously great but I find it annoying the instructions ask your to Set-ExecutionPolicy Unrestricted in order to run the PowerShell script. That is just

by bithush 12y ago

This is obviously great but I find it annoying the instructions ask your to Set-ExecutionPolicy Unrestricted in order to run the PowerShell script. That is just lazy.

Someone1234 12y ago
The default is Restricted, so no scripts can run at all. So they need to tell the user to change it to something. Their choices are AllSigned (or RemoteSigned which is the same thing in this context) or Unrestricted. If they chose the AllSigned route and then sign it with a CA certificate (e.g. Microsoft's Code Signing cert) that would work, but if the user ever made even a one character change to the script the thing will break and it might be unclear as to WHY. Plus you have to be careful not to lose your signature when sending files via certain technologies. Alternatively they could teach the user how to set up a local CA, make a key pair set, and then install. But that too is going to break a lot as it needs to be re-signed each time the script is updated, and obviously inter-machine coding will be a PITA. It is fairly standard practice on non-server developer machines to set it to Unrestricted. It isn't really any more dangerous than for example BAT or VBS scripts which have no such default restrictions. You call it lazy, but the alternatives seem impractical and painful. There are scenarios where you want to enforce code signing, I just don't really feel like a developer machine is one of them.
- toyg 12y ago
  MS screwed up with PowerShell policies. Because the default is so restrictive, corporate sysadmins are worried about altering it to Unrestricted, and signing each script is just impractical, so in practice lots of customers will just refuse to enable it. This is like a Linux distribution shipped OpenSSH disabled by default, and if you enabled it, you'd have to sign every script you run or allow everyone to run (almost) as root. I'm not a fan of PS (coming from Python, PS syntax is just nuts), but it's the most useful tool in the Windows world to automate tasks and deployments of all sorts... or rather it would be, if the security model weren't so inane that few people dare touching it.
  - Someone1234 12y ago
    I don't work for MS so consider this pure speculation: In the past "bad guys" have used VBS to leverage a minor exploit into a full compromise. For example, they might have the ability to write arbitrary strings to the filesystem but not execute or run code. So they write out a *.VBS into the StartUp folder, and when the user reboots they have gone from a relatively minor entry into full remote control. While VBS and BAT remain on Windows based PCs, having PS be locked down is a little irrational. However I suspect Microsoft might be looking to the future when one day they can remove both BAT and VBS (or force the user to enable/install them manually) so that it becomes harder to use such things to escalate your compromise. Essentially they're trying to limit attack surface on 90%+ of consume grade machines, as your average consumer will never run a PS script or even care that they cannot. A lot of medium to large enterprises have an internal CA (with the CA cert already on the machines for authenticating with AD) so internally signing their network scripts is of lower cost (i.e. the infrastructure is all in place, just a single command to sign which you can automate with PS, unlike a solo developer who might not be aware of certificate issues anyway and certainly won't be running their own CA). Your post assumes that PS hasn't been hugely successful, which is definitely not my experience. SysAdmins in the Windows worlds are all over PowerShell, they love it, and if you go read something like SpiceWorks or any other similar community 90% of the new automations are written in PS rather than VBS/BAT (it helps that all of the MS tools in Server 2012 natively support PS). I don't really think the default security restrictions are going to limit PS's popularity, they might limit it for certain niche deployments (e.g. MAKE scripts distributed over the internet) but not for internal use. As far as you not liking PS, I understand, I really do. Most other scripting languages use strings as their fundamental unit of work (e.g. pass strings from process A to B, even over pipes it is all strings or file names which are also strings). In PS the System.Object is the base unit, and everything above that is also an object (it is classic OOP), so it really takes some getting used to. There's a lot of inheritance in there. But once you understand the underlying concepts involve, it is quite de-mystified. However it really helps if you've come from a Java/.Net programming background since even things like overloading isn't really something you'd run across in a scripting language based largely on string transportation. If you want to get started watch this workshop (you don't need to watch the full 4 hours(!)): https://www.youtube.com/watch?v=-Ya1dQ1Igkc https://www.youtube.com/watch?v=-Ya1dQ1Igkc
j_s 12y ago
In case anyone else was wondering, the ideal 'one-time-only' approach appears to be passing '-ExecutionPolicy Bypass' when starting up PowerShell: PowerShell -ExecutionPolicy Bypass -File (...) http://stackoverflow.com/questions/728143/ignore-security-warning-running-script-from-command-line http://stackoverflow.com/questions/728143/ignore-security-wa...

by bithush 12y ago

This is obviously great but I find it annoying the instructions ask your to Set-ExecutionPolicy Unrestricted in order to run the PowerShell script. That is just lazy.

Someone1234 12y ago

The default is Restricted, so no scripts can run at all. So they need to tell the user to change it to something. Their choices are AllSigned (or RemoteSigned which is the same thing in this context) or Unrestricted. If they chose the AllSigned route and then sign it with a CA certificate (e.g. Microsoft's Code Signing cert) that would work, but if the user ever made even a one character change to the script the thing will break and it might be unclear as to WHY. Plus you have to be careful not to lose your signature when sending files via certain technologies. Alternatively they could teach the user how to set up a local CA, make a key pair set, and then install. But that too is going to break a lot as it needs to be re-signed each time the script is updated, and obviously inter-machine coding will be a PITA. It is fairly standard practice on non-server developer machines to set it to Unrestricted. It isn't really any more dangerous than for example BAT or VBS scripts which have no such default restrictions. You call it lazy, but the alternatives seem impractical and painful. There are scenarios where you want to enforce code signing, I just don't really feel like a developer machine is one of them.

toyg 12y ago
MS screwed up with PowerShell policies. Because the default is so restrictive, corporate sysadmins are worried about altering it to Unrestricted, and signing each script is just impractical, so in practice lots of customers will just refuse to enable it. This is like a Linux distribution shipped OpenSSH disabled by default, and if you enabled it, you'd have to sign every script you run or allow everyone to run (almost) as root. I'm not a fan of PS (coming from Python, PS syntax is just nuts), but it's the most useful tool in the Windows world to automate tasks and deployments of all sorts... or rather it would be, if the security model weren't so inane that few people dare touching it.
- Someone1234 12y ago
  I don't work for MS so consider this pure speculation: In the past "bad guys" have used VBS to leverage a minor exploit into a full compromise. For example, they might have the ability to write arbitrary strings to the filesystem but not execute or run code. So they write out a *.VBS into the StartUp folder, and when the user reboots they have gone from a relatively minor entry into full remote control. While VBS and BAT remain on Windows based PCs, having PS be locked down is a little irrational. However I suspect Microsoft might be looking to the future when one day they can remove both BAT and VBS (or force the user to enable/install them manually) so that it becomes harder to use such things to escalate your compromise. Essentially they're trying to limit attack surface on 90%+ of consume grade machines, as your average consumer will never run a PS script or even care that they cannot. A lot of medium to large enterprises have an internal CA (with the CA cert already on the machines for authenticating with AD) so internally signing their network scripts is of lower cost (i.e. the infrastructure is all in place, just a single command to sign which you can automate with PS, unlike a solo developer who might not be aware of certificate issues anyway and certainly won't be running their own CA). Your post assumes that PS hasn't been hugely successful, which is definitely not my experience. SysAdmins in the Windows worlds are all over PowerShell, they love it, and if you go read something like SpiceWorks or any other similar community 90% of the new automations are written in PS rather than VBS/BAT (it helps that all of the MS tools in Server 2012 natively support PS). I don't really think the default security restrictions are going to limit PS's popularity, they might limit it for certain niche deployments (e.g. MAKE scripts distributed over the internet) but not for internal use. As far as you not liking PS, I understand, I really do. Most other scripting languages use strings as their fundamental unit of work (e.g. pass strings from process A to B, even over pipes it is all strings or file names which are also strings). In PS the System.Object is the base unit, and everything above that is also an object (it is classic OOP), so it really takes some getting used to. There's a lot of inheritance in there. But once you understand the underlying concepts involve, it is quite de-mystified. However it really helps if you've come from a Java/.Net programming background since even things like overloading isn't really something you'd run across in a scripting language based largely on string transportation. If you want to get started watch this workshop (you don't need to watch the full 4 hours(!)): https://www.youtube.com/watch?v=-Ya1dQ1Igkc https://www.youtube.com/watch?v=-Ya1dQ1Igkc

j_s 12y ago

In case anyone else was wondering, the ideal 'one-time-only' approach appears to be passing '-ExecutionPolicy Bypass' when starting up PowerShell: PowerShell -ExecutionPolicy Bypass -File (...) http://stackoverflow.com/questions/728143/ignore-security-warning-running-script-from-command-line http://stackoverflow.com/questions/728143/ignore-security-wa...