Security & Execution Policies
Relevant source files
The following files were used as context for generating this wiki page:
- src/System.Management.Automation/security/wldpNativeMethods.cs
- test/powershell/Modules/Microsoft.PowerShell.Security/ExecutionPolicy.Tests.ps1
- src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
- src/System.Management.Automation/engine/remoting/fanin/InitialSessionStateProvider.cs
- src/System.Management.Automation/engine/remoting/commands/NewPSSessionConfigurationFile.cs
Security and Execution Policies within PowerShell constitute a multi-layered defense-in-depth architecture designed to control the execution of scripts and the loading of configuration data. On Windows systems, this system integrates deeply with native security features such as Windows Defender Application Control (WDAC) and AppLocker to enforce system-wide lockdown policies.
The scope of these policies covers local script execution, module importing, and remote session configuration. While execution policies like Restricted, RemoteSigned, and Unrestricted provide a familiar administrative interface, the underlying engine uses native methods to verify file integrity and origin, ensuring that script execution adheres to the platform's security posture.
Sources: src/System.Management.Automation/security/wldpNativeMethods.cs:11-20, test/powershell/Modules/Microsoft.PowerShell.Security/ExecutionPolicy.Tests.ps1:10-25
System-Wide Lockdown Policies
PowerShell identifies the system's security state through integration with the Windows Lockdown Policy (WLDP). This determines if the system is in an "Enforce", "Audit", or "None" mode, which directly impacts whether scripts can run in FullLanguage or ConstrainedLanguage mode.
Enforcement Modes
The SystemEnforcementMode enum defines the high-level state of the system:
- None: No system-wide enforcement.
- Audit: Policies are enabled; execution is allowed but logged for auditing.
- Enforce: Policy restrictions are strictly enforced.
Sources: src/System.Management.Automation/security/wldpNativeMethods.cs:49-62
WLDP and WDAC Integration
The SystemPolicy class manages interactions with wldp.dll. It utilizes WldpCanExecuteFile to evaluate script files against Windows Defender Application Control (WDAC) policies. If a file is deemed unsafe by the OS, PowerShell can block execution or force it into a sandbox.
Execution Policy Levels and Scopes
Execution policies are managed across multiple scopes to provide granular control. These policies primarily affect the behavior of script execution on Windows platforms; non-Windows platforms default to Unrestricted.
Sources: test/powershell/Modules/Microsoft.PowerShell.Security/ExecutionPolicy.Tests.ps1:11-13
Policy Scopes
Policies are checked in a specific hierarchy where more specific scopes override broader ones:
| Scope | Description | Modifiable by User |
|---|---|---|
| MachinePolicy | Set by Group Policy for all users. | No |
| UserPolicy | Set by Group Policy for the current user. | No |
| Process | Affects only the current PowerShell session. | Yes |
| CurrentUser | Affects only the current user (Registry-based). | Yes |
| LocalMachine | Affects all users on the local computer. | Yes (Admin required) |
Sources: test/powershell/Modules/Microsoft.PowerShell.Security/ExecutionPolicy.Tests.ps1:621-650
Policy Types
Commonly tested execution policies include:
- Restricted: No scripts can run.
- AllSigned: All scripts must be signed by a trusted publisher.
- RemoteSigned: Local scripts can run unsigned; downloaded scripts must be signed.
- Unrestricted: All scripts can run, but users are warned for unsigned downloaded scripts.
- Bypass: Nothing is blocked and there are no warnings.
Sources: test/powershell/Modules/Microsoft.PowerShell.Security/ExecutionPolicy.Tests.ps1:194-220, test/powershell/Modules/Microsoft.PowerShell.Security/ExecutionPolicy.Tests.ps1:348-360
Security in Module Loading
The module loading process incorporates security checks to prevent cross-language boundary exploits. This is critical in environments where ConstrainedLanguage is enforced.
Language Mode Consistency
When a module manifest (.psd1) is loaded, PowerShell checks the language mode. If a script module (.psm1) within that module attempts to run in a more permissive language mode than the manifest allows, the system may block it or emit an audit log. This prevents trusted private functions from being exposed to untrusted contexts.
Sources: src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs:640-660, src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs:1340-1360
Security Constraints Table
| Feature | Security Action |
|---|---|
| Implicit Export | Disallowed for functions across language boundaries unless explicitly permitted by manifest. |
| Dot-Sourcing | Disallowed in trusted modules using wildcards for exports under WDAC enforcement. |
| Binary Modules | Analyzed for cmdlets/aliases but language modes do not typically apply. |
Sources: src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs:1330-1355, src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs:1367-1380
Session Configuration Security
Session configuration files (.pssc) define the security boundaries for remote PowerShell endpoints (JEA - Just Enough Administration).
Initial Session State (ISS)
The New-PSSessionConfigurationFile command generates a declarative state for a session. Key security parameters include:
- SessionType: Defines if the session is
Empty,RestrictedRemoteServer, orDefault. - LanguageMode: Forces the session into
NoLanguage,ConstrainedLanguage, orFullLanguage. - RunAsVirtualAccount: Executes the session under a temporary virtual account rather than the connected user's identity.
- VisibleCmdlets/Functions: Implements allow-listing to restrict the available command surface area.
Sources: src/System.Management.Automation/engine/remoting/commands/NewPSSessionConfigurationFile.cs:150-180, src/System.Management.Automation/engine/remoting/fanin/InitialSessionStateProvider.cs:1000-1030
Sequence of Configuration Validation
Summary
The security and execution policy framework provides a robust mechanism for controlling PowerShell's capabilities. By integrating with native Windows security APIs like WLDP and WDAC, PowerShell ensures that script execution is not just a user-level setting but a platform-enforced security boundary. The combination of scoped execution policies, language mode restrictions during module loading, and the granular allow-listing provided by session configurations allows for the implementation of highly secure, "Just Enough Administration" environments.
Sources: src/System.Management.Automation/security/wldpNativeMethods.cs:404-420, src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs:1340-1350