Can't use Add-Type in constrained language mode. What can I do ?

Dear forum readers,

Recently, I decided to set up a software restriction policy on my system. More precisely, everything in standard programs places, such as Program Files or $env:windir is permitted to run, and everything outside requires being authenticode-signed by a specific key.

Then I launched a Powershell window and tried to Add-Type a signed assembly I use often. That assembly is signed with the good key, and regular executables signed with the key start as expected, but Add-Type of that assembly is rejected. It says definition of new types is not allowed in this language mode. I checked my session’s language mode and it’s set to “ConstrainedLanguage”.

I’m surprised of this, since “man about_Language_Modes” says the following about constrained language mode : “The Add-Type cmdlet can load signed assemblies, but it cannot load arbitrary C# code or Win32 APIs.”. The Assembly is signed with the correct signature, so it should work, shouldn’t it ?

In case Add-Type is effectively disabled, contrary to what’s mentioned, what should I do to either 1) load my assembly or 2) have my Powershell start in FullLanguage mode ? I never asked for this constrained language mode, after all.

Thanks for your insights…

Along with that it says below,

allowing only Microsoft signed and Microsoft-certified apps to be installed on Windows RT-based devices

I think, otherwise its a bug. I don’t much with constrained language mode.

You could start your Powershell console with elevated rights.

Thanks for your replies !

@kvprasoon : I’m not on a Windows RT-based device… I don’t normally use that constrained language mode either, it’s just that I’m forced to use it. I’m going to remove that software restriction policy, at least until I’ve found a workaround, right now it’s too annoying !

@Olaf Soyk : If that works, I could as well delete this policy… After all, being forced to run elevated where I shouldn’t have to is not my idea of security, and it’s for security reasons that I set up that software restriction policy.

Software restriction policies or AppLocker policies are made for normal users - not administrative users. If you’re admin on the computer - of course you have the opportunity to bypass any security setting if you realy want to or if you need to.

Of course it can be used to forbid users to run some programs, but it can also be used to mitigate or even prevent some exploits from working. As an example, let’s suppose there’s a weakness in Edge allowing to download an executable file in the temporary internet files directory, and execute it. With my software restriction policy, the executable would simply not execute.

Too bad there’s this constrained language mode restriction coming with it, but if I manage to cope with it I will likely reactivate that policy, and come back to share the results.

I’m too lazy right now, but if I rewrite my assembly as a Powershell binary module and Authenticode-sign it, I suspect it may work…