Move bypass execution policy check after AppLocker Deny check

[TravisEz13]

PR Summary

Move bypass execution policy check after AppLocker Deny check

PR Context

This only affects a corner case where you only have Deny rules.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
      (which runs in a different PS Host).
      • Issue filed:
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
      • Issue filed:
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
      • Issue filed:
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).
      • Issue filed:

[PaulHigin]

Minor comment.

[rjmholt]

@PaulHigin can you refresh your review?

[strawgate]

This seems like it would be a breaking change.... this change appears to make it so you cannot use -executionpolicy bypass to run a script in an applocker environment that is denying script execution

[iSazonov]

This seems like it would be a breaking change

It is a bug fix - no one can disable the lock set by a system administrator.

[strawgate]

Does this being a bugfix effect whether it's a breaking change?

https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md

It doesn't matter if the existing behavior is "wrong", we still need to think through the implications. PowerShell has been in broad use for over 10 years so we be must be extremely sensitive to breaking existing users and scripts.

This would seem to me to be a bucket 2/3 change which previously has required a breaking change conversation even when related to bug fixes: #12766 (comment)

[iSazonov]

@strawgate Any bug fix could be considered as a breaking change :-)

This is a security related bug fix - such things are never discussed publicly (it is Microsoft policy).

[TravisEz13]

@strawgate I've marked the issue a breaking change. As @iSazonov has said, AppLocker is considered the security feature with the stronger promise here. Execution policy was never intended as a bypass.

See our security policy: https://github.com/PowerShell/PowerShell/security/policy

Security issues are treated very seriously and will, by default, takes precedence over other considerations including usability, performance, etc... Best effort will be used to mitigate side effects of a security change, but PowerShell must be secure by default.

FYI, this scenario was is even a corner case of AppLocker, where you only have Deny rules and constrained language mode is not used to enforce the policy.

[ghost]

🎉v7.2.0-preview.5 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes