Posts on this page:
In the previous post, I tried to explain some inconsistences in the current implementation of Constrained PowerShell feature that is introduced in PowerShell 5.0: PowerShell 5.0 and Applocker. When security doesn’t mean security. After having a long email and twitter conversations I realized that many of readers blame me for being against Constrained PowerShell feature. It is not true. In this post, I would like to summarize what is going wrong now and how it should work in my opinion.
A friend of mine asked why his PowerShell scripts (PowerShell profile) doesn’t execute properly in after upgrading to PowerShell 5.0. A brief investigation showed that interactive PowerShell console runs in Constrained Language mode, as the result many language features are stripped out and PowerShell profile isn’t loaded with the following error:
Windows PowerShell Copyright (C) 2015 Microsoft Corporation. All rights reserved. C:\Users\vpodans\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 : Cannot dot-source this command because it was defined in a different language mode. To invoke this command without importing its contents, omit the '.' operator. At line:1 char:1 + . 'C:\Users\vpodans\Documents\WindowsPowerShell\Microsoft.PowerShell_ ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Microsoft.PowerShell_profile.ps1], NotSupportedException + FullyQualifiedErrorId : DotSourceNotSupported,Microsoft.PowerShell_profile.ps1 PS C:\Users\vpodans> [math]::Sqrt(1) Cannot invoke method. Method invocation is supported only on core types in this language mode. At line:1 char:1 + [math]::Sqrt(1) + ~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : MethodInvocationNotSupportedInConstrainedLanguage PS C:\Users\vpodans> $ExecutionContext.SessionState.LanguageMode ConstrainedLanguage PS C:\Users\vpodans>
Update 01.12.2012: clarified Applocker support on server core installations.
Hello folks! Today I want to share some personal opinions about one Windows whitelisting technology — Applocker, especially about the future.
Not all know that this is not something new (as Microsoft promotes), but a next generation of Software Restriction Policies (SRP). SRP is original Microsoft whitelisting technology which was introduced in 2001 (with Windows XP release). Due to various reasons, SRP didn’t become a popular technology that was used by systems administrators (not talking about home users). Microsoft attempted to make SRP more flexible, user-friendly and simple in configuration and usage. As the result, we got SRPv2 called Applocker, which was introduced in Windows 7 and Windows Server 2008 R2.
In one of my recent posts I have posted a bug in AppLocker path rule processing (see: The case of another AppLocker bug). I have opened Technical Support case and AppLocker product group was able to repro the issue and provide a temporary workaround. Here is official Microsoft's response:
We've investigated the issue and it appears to be a problem in the implementation of case-insensitive path comparison for characters outside the ASCII range. Fortunately it seems there is a workaround for the time being. If, in Local Security Policy, one specifies paths in all-uppercase characters, including uppercasing any non-ASCII characters as appropriate, then the rule will match properly. Concretely, for your example 'Mapīte', putting that string with lowercase ī in a rule's path in Local Security Policy will not work; however putting the string 'MAPĪTE' with uppercase Ī does seem to work.
Therefore if path in the path rule contains non-english characters (outside the ASCII 1-127), write these characters in upper case. Unfortunately you cannot use PowerShell for that conversion (by using String.ToUpper() method), because console host doesn't display diacritic characters, so you will have to do this task manually.
Update 23.08.2010: added workaround to resolve the issue.
Today one customer claimed that AppLocker rules are not worked for his environment. He just created simple path rule and it didn't work. I have investigated this issue and I'm able to confirm that AppLocker don't apply path rules to a folder that contains non-english letters. Here is an example how to reproduce this issue. Assuming you have default Windows 7 Ultimate/Enterprise installation with C:\Windows as a system root folder.