Packaged Win32 app and CustomCapability

[DexterWoo]

is it possible for a packaged win32 app process to retain the custom capability declared in the package manifest?

I have this UWP app migrating to Packaged Win32 app with WindowsAppSDK, however there's a security check in the RPC server that will validate the custom capability token, if we cannot get the custom capability to work we might have to roll back to UWP...（oh! god! please don‘t！）

[tysp11]

Hey Dexter!

Could you provide more details on how the RPC server security is implemented? Are you using a custom SD on the endpoint itself, or are you performing some other runtime validation manually, with something like ::CheckTokenCapability ?

If you are using a custom SD on the endpoint, can you provide the full security descriptor in string form?

[DexterWoo]

Hey Dexter!

Could you provide more details on how the RPC server security is implemented? Are you using a custom SD on the endpoint itself, or are you performing some other runtime validation manually, with something like ::CheckTokenCapability ?

If you are using a custom SD on the endpoint, can you provide the full security descriptor in string form?

we are using
<uap4:CustomCapability Name="DolbyLabs.dolbyDAX3ApiService_rz1tebttyb220" />
when it's uwp, the process will have automatically carry the customcapability token with it. so we can validate the token in the RPC Server side to verify if client is trusted by us.
but now when we are packaged Win32 app, that token won't be in the process and we end up not being able to invoke the RPC functions.

[pamorley]

Do you own the RPC server your application (the client) needs to call?

It is very likely that your new application, as a packaged Win32 application, will continue to have access, but we cannot say that for sure without the details of how you are enforcing this in the server

Typically, we would see someone either doing runtime validation in the server process after receiving a client connection, or providing a custom security descriptor to the RpcServerUseProtseqEp / CoInitializeSecurity call

We'd need to see the security descriptor you are applying to the endpoint, or know how you are implementing the capability check in the server at runtime to answer your question

[DrusTheAxe]

but now when we are packaged Win32 app, that token won't be in the process

Why?

You're still a packaged app. CustomCapabilities should be added to the process token because you're a packaged app. The fine print over how your process is created shouldn't change that.

[pamorley]

Capabilities do not have any impact to the OS outside of an access check performed against an app container. An allow-ACE for a capability in a security descriptor, for example, would never come into play unless the subject of the check was explicitly an app container, any non-app container process would simply have to pass the check for the user

I'm not the right person to comment on the feasibility of adding capabilities to non-AC tokens, or if that is possible somehow today. In debugging, I don't see any capabilities on FT packages tokens, so this does appear to be consistent

Regardless, clients should use the provided OS facilities to perform an access check rather than trying to hand-roll their own one and take dependencies on the inner-workings of the process token, as otherwise they're going to be exposed to things like this anytime their assumptions move :(

[DexterWoo]

here's the code for permission check.

static __int64 inline PermissionCheck()
{
        // impersonate the client
	__int64 ulCode = RpcImpersonateClient(NULL);

	if (ulCode != RPC_S_OK)
		return ulCode;

	__int64 i64Result = ERROR_ACCESS_DENIED;
	HANDLE hToken = NULL;

	if (!OpenThreadToken(GetCurrentThread(), TOKEN_QUERY, FALSE, &hToken))
	{
		i64Result = GetLastError();
		TraceEvents(TRACE_LEVEL_ERROR, TRACE_HPD, "OpenThreadToken failed, GLE=%I64d", i64Result);
		goto end;
	}

	PTOKEN_GROUPS pTokenCapabilities = NULL;
	DWORD dwSize = 0;
	if (!GetTokenInformation(hToken, TokenCapabilities, NULL, dwSize, &dwSize) && GetLastError() == ERROR_INSUFFICIENT_BUFFER)
	{
		pTokenCapabilities = (PTOKEN_GROUPS)GlobalAlloc(GPTR, dwSize);

		// Call GetTokenInformation again to get the group information.
		if (pTokenCapabilities != NULL)
		{
			if (GetTokenInformation(hToken, TokenCapabilities, pTokenCapabilities,
				dwSize, &dwSize))
			{
				for (DWORD i = 0; i < pTokenCapabilities->GroupCount; i++)
				{
					if (EqualSid(pTokenCapabilities->Groups[i].Sid, g_capabilitySids[0]) && pTokenCapabilities->Groups[i].Attributes & SE_GROUP_ENABLED)
					{
						i64Result = S_OK;
						goto end;
					}
				}
			}
			else
			{
				i64Result = GetLastError();
			}
			GlobalFree(pTokenCapabilities);
		}
		else
		{
			i64Result = ERROR_OUTOFMEMORY;
		}
	}
	else
	{
		i64Result = GetLastError();
	}

end:

	if (hToken != NULL)
	{
		CloseHandle(hToken);
	}
	return i64Result;
}

g_capabilitySids is created via the following code

// Get the SID form of the custom capability.  In this case we only expect one SID and
	// we don't care about the capability group. 
	if (!DeriveCapabilitySidsFromName(
		L"DolbyLabs.dolbyDAX3ApiService_rz1tebttyb220",
		&g_capabilityGroupSids,
		&g_capabilityGroupSidCount,
		&g_capabilitySids,
		&g_capabilitySidCount))
	{
		hResult = GetLastError();
		goto end;
	}

basically what they do is impersonate as the client, and then try to retrieve the Thread token and check if there's the security token of that custom capability.

[pamorley]

Thanks Dexter,

This will not pass for your packaged Win32 application, since you are explicitly checking for the capability SID. This is not the recommended approach for securing an RPC endpoint, since you are effectively trying to build your own "Access Check" where the OS has facilities in place to do this for you

I would recommend taking a look at https://docs.microsoft.com/en-us/windows-hardware/drivers/devapps/hardware-support-app--hsa--steps-for-driver-developers, it has instructions for how to properly secure an RPC endpoint behind a custom capability

[pamorley]

This approach would pass for your new Packaged Win32 application, assuming the security descriptor you create has an allow ACE for the user group that your application will be running as, for example, IU for interactive users