I ran into a discussion a while back with a collegue that claimed that a lot of clients don't allow us to set up PowerShell scripts for different scheduled maintanence tasks on their servers.

I myself draw a line between signed and unsigned execution of scripts. I have clients that allow unsigned scripts and those clients that doesn't.

But what is the general opinion on this? Is it so bad to allow unsigned scripts? Is there an added safety margin by only allowing signed scripts or is it more hassle than worth it? How do you guys handle it on your machines?

It's a hassle. I doubt many people are willing to run through a process like http://www.hanselman.com/blog/SigningPo ... ripts.aspx, much less the more complex and tedious process that would surround using a real cert that needs real protection (while one could easily argue it's less work than self-signed on every machine, at least there's no chance of losing your One True Cert because Bob's such a ... well, Bob). Especially for some of the two and three line scripts that carry the workloads.

RemoteSigned, though this really is only a safeguard against accidental missteps -- anyone that can edit or create the Alternate Datastream that PS uses to track script origins can bypass RemoteSigned.

As to why, code signing is rather bothersome for powershell scripts that quite often tend to be short hacks to solve a specific problem. With that it is also a real concern that some people would just start to litter their private key on all possible systems, at which point the entire key signing process would rapidly transform into one of those cargo cults that are all too common in IT security.

However, we do use svn/git (source control ALL the things) and a Nagios check that complains if the checked out version/local branch on a system differs from the repository/authoritative remote branch.

There's a good write up on execution policy here. Don't think of it as a way to limit PowerShell in any way. Think of it as a 'safety' to prevent accidentally running malicious code.

On IT workstations we use Group Policy preferences to set RemoteSigned if it is still set to 'Restricted'. Anyone is welcome to change their execution policy and this preference skip over their machine. I spend a good deal of time writing PowerShell and leave mine on bypass. Servers get RemoteSigned as well, tasks run with executionpolicy bypass argument.

If you already have a PKI it's not really a big deal to issue signing certs to your admins and have them sign their scripts. It also means when you term an admin you can revoke his certs and short circuit any timebomb scripts he might have created.

If you already have a PKI it's not really a big deal to issue signing certs to your admins and have them sign their scripts. It also means when you term an admin you can revoke his certs and short circuit any timebomb scripts he might have created.

We have a code signing cert and would have no issues using it for PowerShell. That being said, there is a common misconception:

Quote:

They might think of enforcing an “AllSigned” policy as a way to prevent the user from running non-approved applications, when it is designed as a way to prevent the attacker from running scripts that the user doesn’t approve.

From the article I linked above:

Quote:

At any time, the user can decide otherwise:

Type the commands by handPaste the script into their PowerShell promptCall Invoke-Expression (Get-Content <script>)Call PowerShell –Command (Get-Content <script>)Use our PowerShell hosting APIs to host PowerShell with a different Authorization ManagerWrite their own minishell that has a “Say Yes To Everything” Authorization ManagerLaunch PowerShell in a debugger, and skip the statements that verify the Execution PolicyType PowerShell commands that use private reflection to switch the Authorization ManagerDecompile System.Management.Automation, hack out the Authorization Manager code, and recompile itUse a resource editing tool to modify the LUA manifest, and let Vista do registry virtualization into HKCULaunch PowerShell in a 3rd-party registry or application virtualization program such as SoftGrid or ThInstallUse the Application Compatibility toolkit to write your own shimInject API hooks into PowerShell.exe (Overview, Tool, SDK)(etc)

I do agree that they have their place, but I would never place any reliance on a function they weren't designed to perform. As Lee Holmes mentioned,

Quote:

System-wide PowerShell Execution Policies have never been a way to prevent the user from doing something they want to do. That job is left to the Windows Account Model, which is a security boundary