Closed S-T-S closed 3 years ago
Does the SAW policy allow the SecretManagement module to run as trusted? If it does and you still get this error, then that would be a bug needing investigation. But any PowerShell module running on a SAW should be vetted and allowed by the policy. Otherwise it is run in constrained language mode and will fail.
/cc @TravisEz13
@PaulHigin each module has to be signed specifically for SAW use.
We could detect that we are in constrained language when the module loads and give a better error message.
I believe there is a little bit of effort to allow SecretsManagement work in Constrained Language Mode.
Based on the code itself it looks like the module is calling String Constants which are invoked as a script https://github.com/PowerShell/SecretManagement/blob/b1fbbd0e7f4c0e035e7a2d495472f8a2790fe04d/src/code/Utils.cs#L357
This means that the "invoked" scripts are being called and CHECKED against Constrained Language Mode, and all the beauty it entails. That means its like dot sourcing the code essentially.
So in short the Constant strings need to be CLM Compliant before they can be executed.
I would say right now adding a fail-fast before execution would be a great first effort, but I would love to see this prioritized so that Security Focused Teams/Organizations can leverage this amazing tool.
The CL mode issue is not in this module but in the SecretManagement module. I have this issue tracking the problem. https://github.com/PowerShell/SecretManagement/issues/144
Or, a security configuration prevents the operation of a security tool.
On a Secure Admin Workstation or SAW that is configured to run Windows Powershell and/or PowerShell in a Constrained Language mode Microsoft.PowerShell.SecretStore errors.
Or we update documentation to specify Full Language mode required.