Support mixed security context configurations

[SteveL-MSFT]

Summary of the new feature / enhancement

A configuration may require parts to be elevated and also parts to be restricted. This is already supported for the whole doc via metadata, but this needs to be extended to specific resources.

Proposed technical implementation details (optional)

Initially, if a configuration requires mixed, we should require that the user be elevated and during execution, dsc creates a restricted process to run the resources that specify restricted.

Later, if a configuration requires mixed, dsc can detect this and prompt at the start (UAC on Windows and sudo on non-Windows) to spawn a child dsc process that is elevated that actually executes the configuration and handles restricted the same as the initial implementation above.

One potential technical challenge is reading/writing standard io across elevated and restricted processes.

[michaeltlombardi]

How do configuration authors indicate that a specific resource requires a different security context? Do they specify it in the _metadata property of the resource instance, or with a particular group resource (e.g. Microsoft.Dsc/SecurityContext), or both?

The downside to a group resource is it can't be used in a group that isn't implemented by spawning a child dsc process, like the current adapters or any externally implemented group resources, but it's much more convenient when grouping non-nested instances.

The only downside to _metadata that I can see immediately is the plumbing complexity. It seems like it would require adapter/group resources to have a more careful integration or risk folks trying to duplicate the functionality for switching security contexts.

[SteveL-MSFT]

I think it'll just be a _metadata property under Microsoft.DSC namespace same as how you specify it for the whole config, but per resource. Adapter/group resources shouldn't care (excluding within their own properties) as dsc will spawn the adapter/group under the required security context.