Repository navigation
Add ability to configure internet zone server names for execution policy in PS v7 #12336
Description
Activity
Ilya (@iSazonov) There are no Execution policies on Unix. Let's not add scope creep to this.
files only current user accessible by permissions. It is folder redirection scenario. If untrusted user has an write access to a file we can not trust the file.
To provide some context, in our environment our user folder permissions are set up as follows:
-
User has Modify permissions to their entire user folder at \\server.domain.com\Users\Username and all subfolders.
-
Delegated file server administrators have Modify and Full permissions via security groups to all files and folders in the Users share (these permissions are inherited from higher folder levels).
I mention this to clarify that while in practical terms only the end user has access to the user's folder, and no other regular users have access to the user's folder, technically, the file server administrators are visible in the ACLs of the folder in case your proposal is querying the ACLs of the file.
In our scenario, we would still need to trust folders that may exist outside of redirected folders too, so we will likely use option 3 from above (Get trusted patterns from config file/GPO) and hence may not need this, but another way to address redirected folders is to consider trusting the locations of the known SpecialFolders Documents and Desktop. There is also the issue though when querying "[Environment]::GetFolderPath("MyDocuments")" on a system that has AppLocker since PowerShell runs in Constrained Language Mode and hence is unable to run this code to identify the path Documents folder path. But if PS can still query that somehow and trust it, that could be an option too.
-
Ilya (@iSazonov) This feature is scoped to discovering host names zones. Please stay on topic. There is no change requested to how files work. Execution Policy has never considered ACLs. We are not expanding execution policy functionality. We are only restoring functionality that was lost in the port to PowerShell Core.
MyDocuments can be modified by the user (assuming it is not controlled by group policy) and would defeat the purpose of this feature. It would also be a much more limited feature and querying this does not work on all editions of windows.
If we don't trust the server, we cannot trust the ACLs on the server so they would be an unreliable way of verifying the server.
Ilya (@iSazonov) This is a different feature than requested and out of scope. Please file a new issue if this is what your would like to discuss as this is a much longer discussion. I will keep marking this like of discussion as off topic as it will only delay this request simple request.
Broad implementation plan:
-
add a new configuration array with a list of servers to
ScriptExecution:
-
Implement the logic to read it and return true if it is in the list here:
Reference:
- Here is an example of how to read the policy:
-
14 remaining items
Brilliant, I have assigned this to you and will look forward to seeing the resulting PR when it comes around!
Hey, any news on this topic?
that's really sad. 😞 please reopen. requirements are still preset
Reacted by Sean Thompson and fhlbdvtMister Sausage (@MisterSausage) Hi, are you able to manage this ? as this issue is open since 4 years ?
Can we provide any help to go forward ?
For reference: https://gist.github.com/VimalShekar/c781ed8a9d638270b88634ad3eaada72
Gist
Instantiating IInternetSecurityManager interface in PowerShell - gist:c781ed8a9d638270b88634ad3eaada72
Summary of the new feature/enhancement
Background
Currently the PowerShell policies assume that if there is a "." (period) in a PowerShell script's path, that it is in the internet zone. This presents the user with a warning when running PowerShell scripts are from a FQDN path (like \\server.domain.com).
In PowerShell versions up to v5.1, Windows Domain Administrators could define specific domains to be added to the Local Intranet Zone. Once added, PowerShell would then "trust" these paths when the ExecutionPolicy=Unrestricted and not present the user a security warning for each script that is run from these trusted paths.
#7458 revealed that PowerShell Core (v6 and v7) intentionally removed the legacy IE API that was previously used to check the Local Intranet zones, and was replaced to check for just "." (periods). As per Travis Plunk (@TravisEz13) in #7458 I am creating this new feature request to discuss and address this problem.
Impact Of Changes Made In PowerShell Core
Many Windows environments use a feature called Folder Redirection such that the user's "Documents" folder is "redirected" to a server (so it appears to the user that their Documents folder is on their computer, but it really lives on the server). Many environments that use folder redirection redirect to a FQDN UNC path like \\server.domain.com\Users\username\Documents. Since these paths contain "." (periods), any script run from the user's Documents folder is presented with the PowerShell Security warning. This warning message also appears if the user has a PowerShell profile and starts PSv7, which presents this message each time:
So in any environment where either Folder Redirection is being used to a FQDN UNC path, or if the environment presents users their User/Department folders on a FQDN UNC path, this will trigger security warnings and will present problems to the end user if they try to run scripts from these locations. (At this time, we cannot deploy PowerShell v7 in our environment due to this problem).
Additional details about the problem and the discussion are available in #7458.
Goal
Allow Windows Domain Administrators to configure what FQDN hosts are safe and not trigger a warning when using the Unrestricted execution policy. This would allow Windows Domain Administrators to set up PowerShell v7 so that users are still presented the security warning when running scripts from untrusted paths, but do not trigger this security warning when scripts are run from trusted paths when the ExecutionPolicy is set to Unrestricted.
Windows Domain Administrators will also need the ability to add trusted/safe hosts via the PowerShell Core Group Policies to help deploy these trusted hosts to all domain computers.
While the ability to trust FQDN hosts would solve the immediate problem and is the main problem I am hoping to have addressed, it would also be helpful if PowerShell administrators had the flexibility to not just add FQDN hosts (and all shares/files on it), but also specify paths with subfolders and wildcards. So for instance PowerShell Administrators could either choose to trust a FQDN host like server.domain.com, but also have the flexibility to trust a path like \\server.domain.com\Users\*\Documents\PowerShell*.
Proposed technical implementation details
Steve Lee (@SteveL-MSFT) and Travis Plunk (@TravisEz13) suggested the following proposal to help address this problem in #7458:
And thank you for your time with this!