puppetlabs / ruby-pwsh

A ruby gem for interacting with PowerShell
MIT License
15 stars 23 forks source link

Protected Event Logging is breaking execution #188

Closed chelnak closed 2 years ago

chelnak commented 2 years ago

Both DSC resources and anything with a provider => powershell is immediately erroring out with errors as follows:

#<Thread:0x0000000005efc6a8@C:/ProgramData/PuppetLabs/puppet/cache/lib/pwsh.rb:587 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
        1: from C:/ProgramData/PuppetLabs/puppet/cache/lib/pwsh.rb:589:in `block in read_streams'
C:/ProgramData/PuppetLabs/puppet/cache/lib/pwsh.rb:589:in `sysread': end of file reached (EOFError)

See Slack thread for more discussion and a link to the ZenDesk ticket.

chelnak commented 2 years ago

I'm not having much success with the repro for this issue.

The following image shows some basic info from my test rig.. You can see that applying test.pp works with no issue:

image

Also Protected Event Logging is enabled and encrypting events as expected:

image

The main thing that perplexes me right now is how the encryption of the logs is correlated with the output of the PowerShell provider.

cummingscody commented 2 years ago

image002 Attaching docs and further info from customer...

Also, this is coupled with the GPO "Turn on PowerShell Script Block Logging" set to "Enabled". In testing I've found that the errors don't occur if "Protected Event Logging" is enabled, but that policy is not.
chelnak commented 2 years ago

Great news! That extra info helped me replicate the issue 😄

image
chelnak commented 2 years ago

Fixed in #189

For each run we reset the session environment to a last known good state. We did this by removing all environment variables, then re-setting them from a cached set we took at the start of the run.

It appears that when ScriptBlock Logging and Protected Event Logging are both enabled, removing the SystemRoot environment variable from the current session causes PowerShell to crash.

I'm unclear at this time what the dependency is but suspect that there is a process that is consuming $env:\SystemRoot when building a path to an executable.

I was able to replicate by manually invoking init.ps1 with a custom name and redirecting pwshlib to the new pipe. Once you do this you can see the whole error message. It talks about a missing environment variable...

image

A bit of trial and error narrowed it down to SystemRoot.

189 fixes the issue by filtering out SystemRoot from the list and only removing the remainder.

The questions remaining for me are:

  1. When the two settings are combined, what causes the dependency on SystemRoot?
  2. Would it be better to scope the filtering to only happen when the two settings are both enabled?