PowerShell Core configuration

[iSazonov]

No description provided.

[markekraus]

Somewhere in here powershell.config.json should have a JSON Schema... though.. since JSON schema is still in draft... I'm torn on whether to fight for that or not.

https://tools.ietf.org/html/draft-handrews-json-schema-00

[iSazonov]

Actually the RFC describe the schema implicitly.
Current API implementation uses string typed approach - we can secure without strong scheme check.
So we'd need the scheme explicitly only if we'd introduce configuration cmdlets like Test-PSConfig, Get-PSConfig, Set-PSConfig.

[markekraus]

@iSazonov that's not what I meant... I meant that the JSON file should have a publicly available schema. The JSON Schema defines all the object properties, their acceptable types, etc. This schema can then be linked in the powershell.config.json with the $schema property. Then in editors like VSCode you can have auto completion and selections available. This schema would require updating when new settings are made available in powershell.config.json.

More info http://json-schema.org

[iSazonov]

@SteveL-MSFT Time is over. Could we continue?

[TravisEz13]

Regular setting should be deployed via GPP not GPO

[TravisEz13]

GPP is for setting the user can change.

[iSazonov]

We're talking about values in the registry. In this case, the user can change any value if it has permissions (mainly in HKCU). (Of course then this value will be overwritten by GPO or GPP)

I don't see the point of distinguishing between regular settings and policies by name. What is the criterion? We are able to set the value in the registry using GPP in the Policy branch (even in HKLM) and thereby assign the policy.

The only question is who, how and for what set/changes the settings. System administrators or security administrators will most often use GPOs to set mandatory standard values that are less likely to GPP to set recommended values.

This document tries to describe all the ways that can be to provide maximum flexibility and also how to get an effective value based on priority.

[TravisEz13]

GPP has the ability to not overwrite if the user changes the registry.

[TravisEz13]

Also, GPO implies that the setting is policy, which this setting is not. It is a preference.

[SteveL-MSFT]

Removing Review - Committee as there's additional comments now

[rjmholt]

One point I would be interested in addressing is that PowerShell will modify a powershell.config.json file at runtime. That works well until there are more than one PowerShell process running, which have no business sharing state.

I feel like it might be worth discussing those config fields which are settable and working out whether they should be system globals or process-specific. Execution policy is one example.

[rjmholt]

I would use bold for key terms, rather than backticks.

[TravisEz13]

@iSazonov Can you update this for how -settingfile should work. I'm not sure how it works currently fits in properly with this spec.

[iSazonov]

@TravisEz13 I added a comment about -settingfile.

[TravisEz13]

When we are in lockdown mode, even elevated users should not be able to overwrite computer-wide settings

[iSazonov]

Only users with elevated rights can overwrite computer-wide and user policy settings.

I do not know how to formulate it right at the same time for Windows (GPO) and for Unix (only files).
In fact, the administrator always has the ability to change any setting.
Maybe remove the sentence at all?

[felixfbecker]

I find it a bit inconsistent that this config file is using JSON while other PowerShell config files like module manifests use .psd1. Why choose JSON here?
And if JSON is chosen, I find it weird that properties are PascalCase. I realise that is the convention for PowerShell code and C#, but JSON is JavaScript Object Notation, and the convention is camelCase.

[TravisEz13]

Can ScriptBlockLogging\* and ProtectedEventLogging\* also be configured via policy?

[iSazonov]

If logging settings refers to security then this make sense.
(Here I meant that all the settings listed can be either policy or regular)

[TravisEz13]

These setting plus execution policy are Security related.

[TravisEz13]

ModuleLogging also..

Transcription would not be set system wide, it would need to be per user or it's better to use scriptblock logging. IMHO.

cc @PaulHigin

[rjmholt]

@felixfbecker I think JSON was chosen for the file to be portable outside of PowerShell. JSON has very strong and widespread tooling and if your configuration is broken and you can't start PowerShell, a PSD1 parser will be harder to come by. In the time since PowerShell modules were conceived, JSON has risen to dominance as a widespread, simple, well-supported and relatively safe way to encode this kind of simple structured data.

On the convention note, JSON doesn't seem to have an agreed convention and PascalCase allows a lower representational gap between the JSON file and the internal classes/settings it represents.

[iSazonov]

@TravisEz13 @daxian-dbw What security setting can be in the config that we need to worry about? Or for simplicity, we should consider all settings as security?

I suggest the algorithm:

• at startup
  • PowerShell Core has explicit defaults for all config settings (secure by default that allow avoid the need to crash at startup)
  • PowerShell Core tries to read the config and get settings
  • if any error then keep "current settings" that is defaults at the time and logging a warning (The logging will allow us to get feedback if users see something strange in the logs.).
• at runtime
  • PowerShell Core tries to read the config async every n-minutes (5?) (Windows applies GPO every 90 minutes by default and we could implement a callback but seems . )
  • if any error then keep "current settings" and logging a warning

I suggest open the config with options "For Read" and "Share.ReadWrite". Latest allow us avoid a trouble (keeping current settings) if file already locked by another process for write long time. The above algorithm allows us to do it safely because no need to crash.

[rjmholt]

Another thing that might be worth addressing in this is path handling in the config file. Since JSON is a static asset, writing a redistributable config file that works on all platforms is not possible if all paths are taken as literal.

Should PowerShell do any kind of handling for paths here? And what about environment or automatic variables?

I can imagine a desire for something like:

{
    "PSModulePath": "${env:windir}\\System32\\WindowsPowerShell\\v1.0\\Modules"
}

I can also imagine wanting to write something like:

{
    "PSModulePath": "$HOME/PowerShell/Modules<sep>$PSHOME/Modules"
}

and have it work on Windows, Linux and macOS with <sep> being the right path separator, $HOME and $PSHOME resolving properly, and the / in the paths working on Windows.

Finally, another question is, should we handle relative paths at all? Possibly as relative to the config file itself?

[TravisEz13]

@iSazonov Secure by default is difficult to achieve. We would have to generate a unique encryption key and setup protected event logging. We would need to store that configuration somewhere. What happens if we cannot store that? How do we know if we have already setup a default? Using a hardcoded default would be insecure. How do we secure the key we generate?

[iSazonov]

Using a hardcoded default would be insecure. How do we secure the key we generate?

@TravisEz13 Under "secure by default" I meant that we hardcode the secure defaults internally in code.

not possible if all paths are taken as literal.

@rjmholt We can process literal paths in PowerShell (LiteralPath parameter). I don't see problems.
As for env variables and relative paths I don't know.

[rjmholt]

We can process literal paths in PowerShell (LiteralPath parameter).

By "literal" I mean, interpreting the path verbatim as .NET would, rather then resolving it in PowerShell. As far as I know, we currently just pass the paths straight to .NET APIs, but to get a cross-platform config we'd want to do /-\ conversion etc etc.

And thinking on it more, it might be worth having a short whitelist of variables like $HOME and $PSHOME that we guarantee usage of.

[iSazonov]

we currently just pass the paths straight to .NET APIs, but to get a cross-platform config we'd want to do /-\ conversion etc etc.

Currently .Net Core does the normalization on Windows. Sample https://source.dot.net/#System.Private.CoreLib/shared/System/IO/Path.Windows.cs,220

[rjmholt]

Currently .Net Core does the normalization on Windows. Sample https://source.dot.net/#System.Private.CoreLib/shared/System/IO/Path.Windows.cs,220

Absolutely, but in PowerShellEditorServices I've seen bugs where a \ in *nix isn't treated like a path separator. That's all I mean there.

[joeyaiello]

Hey @iSazonov, we would love to take a hard look at an updated version of this. Would you mind giving it a read to make sure it makes sense with what's happened in the last year, as well as to fix the broken table you have near the beginning? Thanks!

[iSazonov]

@joeyaiello Table was fixed. I added new section about defaults. I set out my vision. Your team can make changes to speed up the work if necessary.

[joeyaiello]

@iSazonov is any of this one still relevant now that RFC0041 has been merged? If so, can you scope it to those changes? If not, can you close this PR?

Sorry, I know we've dragged our feet on this one, but I'm fairly certain a lot of this thinking served as the basis for RFC0041. Thanks for going through this exercise to help guide that one.

[iSazonov]

@joeyaiello Please look this https://github.com/PowerShell/PowerShell-RFC/blob/master/4-Experimental-Accepted/RFC0041-Policy.md#acknowledgement
I am not sure that I understand that is "a slightly different purpose" of the RFC0041 and that was rejected in the PR but this says that RFC0041 does not cover all from the PR.

[joeyaiello]

I'm not sure the underlying motivation of the PR matters so much as the implementation as it exists.

Is there an aspect of this RFC that you'd still like to offer forward that wasn't in RFC0041?

[iSazonov]

@joeyaiello After reviewing RFC0041 and the PR I find 2 gaps:

1. GPP (group policy preferences). I think it is important for Enterprises. But this was rejected by MSFT team so I leave this to your team.
2. Issue Some cmdlets and config require writing to $PSHOME\SessionConfig folder PowerShell#9278 should be addressed in new RFC and code