Module signature validation is enabled by default

[mhollismcgill]

This issue applies to standalone DSC, not the OMS build.

To replicate the issue:

1. Use the most recent version of the Azure DSC VM extension to register a VM with an Azure Automation DSC pull server
2. Assign to the node a DSC mof which uses a custom resource
3. The configuration will fail, and checking /var/opt/omi/log/dscdetailed.log will reveal the error is caused by signature validation failing on the custom resource

Based on the code in dsc/engine/ca/CAInfrastructure/WebPullClient.c it looks like this behavior is not intentional:

MI_Result MI_CALL Pull_GetModules(_Out_ MI_Uint32 * numModulesInstalled,
                                  const MI_Char *configurationID,
                                  const MI_Char *certificateID,
                                  MI_Char* directoryPath,
                                  MI_Char* fileName,
                                  MI_Char** result,
                                  MI_Uint32* getActionStatusCode,
                                  MI_Boolean bAllowedModuleOverride,
                                  _In_reads_z_(URL_SIZE) const MI_Char *url,
                                  _In_ MI_Uint32 port,
                                  _In_reads_z_(SUBURL_SIZE) const MI_Char *subUrl,
                                  MI_Boolean bIsHttps,
                                  MI_Instance **extendedError)
{
    ModuleTable moduleTable;
    ModuleTableEntry* current;
    MI_Result r;
    MI_Value value;
    int retval = 0;
    char zipPath[MAX_URL_LENGTH];
    char stringBuffer[MAX_URL_LENGTH];
    char * verifyFlag = "1";

    moduleTable.first = NULL;
    r = GetModuleNameVersionTable(fileName, &moduleTable, extendedError);
    if (r != MI_RESULT_OK)
    {
        CleanupModuleTable(moduleTable);
        return r;
    }

    r = MI_Instance_GetElement(g_metaConfig, MSFT_DSCMetaConfiguration_DisableModuleSignatureValidation, &value, NULL, NULL, NULL);

    if (r != MI_RESULT_OK)
    {
#if !defined(BUILD_OMS)
	// default is to not verify
	verifyFlag = "0";
#else
	// default is to verify for oms
	verifyFlag = "1";
#endif
    }
    else
    {
	if (value.boolean == MI_TRUE)
	{
	    verifyFlag = "0";
	}
    }

Note that the default behavior, if BUILD_OMS is not defined, is to not validate module signatures. This makes sense because I believe it matches the Windows DSC behavior, and also the DSC extension does not provide any method of importing a PGP key to the DSC keychain, so it would be difficult to use custom resources if the default behavior was to validate signatures. Somehow though the default behavior is to validate signatures, even though using the DSC extension to register a node to a pull server results in DisableModuleSignatureValidation = NULL in the metaconfig. If I had to guess, I'd say that MI_Instance_GetElement is actually returning MI_RESULT_OK even if DisableModuleSignatureValidation = NULL, and value.boolean == MI_FALSE in this case. However, there is no code to handle value.boolean == MI_FALSE, so the value of verifyFlag is never set beyond its initialization. You can see that verifyFlag is properly initialized, and it is set to "1", which is sensible in a way because that's secure by default.

This default behavior looks unintentional, and it is a problem for my team because we need to use custom resources with DSC for Linux. Apart from custom resources just being useful in some respects, we need to use them because the builtin nxScript resource will break on hardened images (since it tries to execute a script in /tmp, which for security reasons is mounted as noexec on hardened images).

Just let me know if you have any questions.

Thanks,
Matthew