Repository navigation
$PROFILE on a shared folder gives security warning if remote system has periods in the name #7458
Description
Activity
Bill Loytty (@weloytty) Have you tried using a signed file?
No, because it's my profile and I mess with it a lot. (I have run Unblock-File $PROFILE though, since that's what the error message tells me to do, and I get the same behavior once I have done that)
I also end up with my modules folder on a UNC share too, and I get the same behavior. I could move my profile to $profile.AllUsersCurrentHost, but I'd prefer to keep the 6.0.3 behavior.
Bill Loytty (@weloytty) Could you please compare the scenario with Windows PowerShell?
Windows powershell behaves the same way that pwsh 6.0.3 does, it loads my profile with no warnings
Steve Lee (@SteveL-MSFT) Could you please comment the use case? I'd expect that we could trust signed scripts at least.
Ilya (@iSazonov) and Bill Loytty (@weloytty) I think this behavior is correct as the script is still residing in a remote location. Execution policy is always for a script which is available locally(no matter from where it is developed). Correct me if I'm wrong.
The default ExecutionPolicy is
RemoteSignedand a network share isRemoteso this behavior isby-design. Other than signing the script, the other solution is to change your execution policy.Steve Lee (@SteveL-MSFT) It's by design even if my executionpolicy is Unrestricted?
`
PS C:\Users\someone> get-executionpolicy
Unrestricted
PS C:\Users\someone> .$PROFILESecurity warning
Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your
computer. If you trust this script, use the Unblock-File cmdlet to allow the script to run without this warning
message. Do you want to run \na.something.com\WLNC-UD$\UD3\someone\My
Documents\PowerShell\Microsoft.PowerShell_profile.ps1?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D"):`
Your profile script is both unblocked and executionpolicy is unrestricted? Can you try
bypassexecution policy?Correct, I have run unblock-file $PROFILE and execution policy is unrestricted.
-ExecutionPolicy Bypass worked as expected (no prompt when running profile).I've attached a transcript of what happens, starting from cmd
7548.txtBill Loytty (@weloytty) thanks for the details, I'll see if I can repro this locally. I would suggest removing the network paths in your transcript to something generic like
\\server\shareas to not make internal information publicReacted by AhmedAbdelrazzakproblem still exists in RTM
I also have the same problem over here with RTM version, ExecutionPolicy = Unrestricted
For every loaded module and $profile I have to confirm it and there is no option to Confirm All
I even tried adding the UNC path to Trusted Sites but no success. Any help how to solve this? I didn't have this issue with the previous version.. Many thanksReacted by Bill LoyttyKurt De Greeff (@KurtDeGreeff) can you be more specific about "previous version"? It would help to know when this was changed so we can find the change that caused this. Thanks.
30 remaining items
It seems some non-MSFT applications utilize the IE feature. Perhaps there is a public api?
Another thing to note is that the zones can be queried via the registry from the following locations:
Computer: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains
Computer Group Policy Set: HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey
User: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains
User Group Policy Set: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey
Values set to 1 indicate a Local Intranet zone.
So even if the IE API can't be used, these registry locations can be queried to calculate sites in the Local Intranet zone.
Perhaps this may be easier to reference versus trying to build out a new mechanism to store trusted locations.
Thanks!
aakash-shah You referenced IE regkeys for non-enhanced protection mode.
I'd like to still make it harder for my users to run a script from any random UNC path.
Why do you want to make it harder to run from a random UNC path. Please include some reason for this. This seems arbitrary and cruel to your users. I really need to understand your reasoning to make sure attempting to fix this make sense.
Update:
Actually, that statement shows enough of your reasoning. You want to make it harder. Let's accept this as your goal and move on.
Another thing to note is that the zones can be queried via the registry from the following locations:
Implementing our own algorithm to parse the registry keys would likely introduce a very large number of bugs, when we have one now.
It seems some non-MSFT applications utilize the IE feature. Perhaps there is a public api?
This still ignores the fact that IE will not ship on many editions of windows going forward.
If we need this feature, let's design it for compatibility. Not so we have to rewrite it in 7.2.
Reacted by IlyaIt seems some non-MSFT applications utilize the IE feature. Perhaps there is a public api?
This still ignores the fact that IE will not ship on many editions of windows going forward.
If we need this feature, let's design it for compatibility. Not so we have to rewrite it in 7.2.
I may be assuming incorrectly here, but even if IE isn't installed, Windows still references and uses these settings for Windows Explorer. For instance if you open a file from a FQDN path, and that path is not in the Local Intranet zone, it gives you some extra warnings when opening Office files. After we add the Windows domain FQDN paths to the Local Intranet zone, it corrects that problem, and files from the FQDN UNC paths open as expected in Windows Explorer with no warnings. I haven't tested removing IE, but I assume this will need to continue to work since even though the Local Intranet settings are accessible from within IE, they apply in other areas of Windows too.
If my understanding is incorrect about this changing when IE is removed, please let me know.
Thanks!
We can't rely on IE APIs. What I propose is that we add definitions of trusted remote systems in our powershell.config.json file.
Reacted by Rain Sallow (/u/ta11ow), Travis Plunk, Ilya, Szeraax, David Söderlund and v'KarasI agree with Steve Lee (@SteveL-MSFT) . We can add it to the powershell.config.json. Have PowerShell wildcard support. This is design uses existing code that would be less likely to have new bugs.
We can't rely on IE APIs. What I propose is that we add definitions of trusted remote systems in our powershell.config.json file.
Steve Lee (@SteveL-MSFT) , Travis Plunk (@TravisEz13) Can we use Group Policy to add trusted remote systems into the powershell.config.json file? If not available today, can support for this be added so that IT admins have a way to easily add support for this in our environments? Group Policy support will help IT admins significantly, and help improve adoption of PSv7.
So that I understand this better, would these trusted remote systems be defined using the DNS name only, or would we also need to specify the entire path? For instance, would we define "server.domainname.com", or would we define something like "\server.domainname.com\users*\Documents\PowerShell"? If this is already documented somewhere, feel free to point me to it.
Thanks!
I'd suggest that someone file a new feature request so that we can start with a clean issue that we can discuss the merits of this proposal.
Title: Add ability to configure internet zone server names for execution policy
Summary of the new feature/enhancement
Background
Currently the policies assume that if there is a
.in the name it is internet.
This feature is needed to warn users if they are leaving the internet zone unintentionally.Goal
The goal would be allow the PowerShell Administrators to configure what hosts are safe and will not trigger a warning by execution policy.
Proposed technical implementation details (optional)
- A list of allowed host filters, that allow PowerShell Wildcards in the
powershell.config.json.
Note: On Windows
powershell.config.jsoncan already be configured via Group Policy. See PowerShell PolicyReacted by Ilya and David Söderlund- A list of allowed host filters, that allow PowerShell Wildcards in the
Travis Plunk (@TravisEz13) Steve Lee (@SteveL-MSFT) Thank you very much for your time in reviewing this thread and replying to my comments/questions! As requested, I've created #12336. Please let me know if there is anything else I should add.
Thanks!
aakash-shah You referenced IE regkeys for non-enhanced protection mode.
Ilya (@iSazonov) Yes you are correct! I missed the IE ESC keys under [HKLM | HKCU]\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains. Thanks for pointing that out!
Bill Loytty (@weloytty) thanks for the details, I'll see if I can repro this locally. I would suggest removing the network paths in your transcript to something generic like
\\server\shareas to not make internal information publicSteve Sanderson (@Steve) Lee
you made my day,
your recommendation about removing the dots solved my issue as I was writing the path as follow "10.x.x.x"
Thank you very much
Tested on 6.1.0-preview.4 6.1rc, 6.1 release, and 6.2-preview.1
Steps to reproduce
Expected behavior
My profile loads, as it does with 6.0.3
Actual behavior
If I say [R]un Once, my profile will load, but I will get the same message for every module in my profile.
Environment data