Automating the world one-liner at a time…
Derek Melber has a very good analysis/summary of the PowerShell security over at WindowsSecurity.Com. If you run across someone concerned about the security aspects of PowerShell, this would be a good article to point them to. The article is HERE.
Jeffrey Snover [MSFT]Windows Management Partner ArchitectVisit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShellVisit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
PingBack from http://msdnrss.thecoderblogs.com/2007/11/16/powershell-security/
I've read a number of articles about PowerShell's security, and they all cover pretty much the same set of features. Some do a better job of explaining the issue with running scripts from the current directory, and some mention additional ideas such as that scripts can't be launched from Windows Explorer by double clicking, etc.
None of the articles I've read, however, have explained the actual thinking behind the execution policies. Most articles even leave the definition of 'RemoteSigned' as fairly woolly: nobody who needs an article like that is going to understand that a script from a downloaded zip file isn't remote, or that non-Microsoft browsers don't generally mark ps1 files as coming from the internet, etc.
I'd really like to understand how the execution policy helps, when everyone who installs PowerShell disables it as soon as they encounter it. I can see a case for the setting as configured by group policy, but not for the default being 'Restricted'. I want someone to explain why this isn't the wrong trade-off; the result of an organisation too frequently bitten by insecurity to even consider ussability.
I'm not convinced the execution policy helps anyone right now; the lack of simple file association is a much more practical measure. I need someone to justify it, not simply to explain it.