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

Welcome Forums General PowerShell Q&A Can't use Add-Type in constrained language mode. What can I do ?

This topic contains 5 replies, has 3 voices, and was last updated by

 
Participant
1 month, 1 week ago.

  • Author
    Posts
  • #120297

    Participant
    Points: 21
    Rank: Member

    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...

  • #120322

    Participant
    Points: 814
    Helping Hand
    Rank: Major Contributor

    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.

    • #120472

      Participant
      Points: 21
      Rank: Member

      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.

  • #120339

    Participant
    Points: 245
    Helping Hand
    Rank: Participant

    You could start your Powershell console with elevated rights.

  • #120487

    Participant
    Points: 245
    Helping Hand
    Rank: Participant

    ... 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.

    • #120855

      Participant
      Points: 21
      Rank: Member

      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...

You must be logged in to reply to this topic.