Windows 11 AppContainer: Is a package SID ACE with CRITICAL_ACE_FLAG equivalent to an inherited capability SID ACE?

Hello @Remi Poirier and thank you for reaching out. 

Based on the available public documentation and the results I obtained from testing, I can address your three questions as follows. 

1. Does CRITICAL_ACE_FLAG have security semantics in this Windows AppContainer filesystem scenario that would not be reflected by ordinary AuthzAccessCheck results? 

I could not find public Microsoft documentation that defines the semantics of CRITICAL_ACE_FLAG in this scenario. 

In my testing, two ACLs that differed only by this flag produced the same AuthzAccessCheck results for all five requested access combinations, and the six preserved descriptor pairs also produced matching results for the tested tokens and rights. Therefore, the flag made no difference in the tested access checks. However, the public documentation does not establish whether Windows uses it for another purpose outside this access-check behavior. 

2. Can a package SID ACE and a capability SID ACE provide the same tested rights to the current process while differing in their authorization of other AppContainers? What supported method would establish that distinction? 

Yes. A package SID and a capability SID are different security principals. The package SID identifies a particular AppContainer, while a capability SID represents an authority that may be held by multiple AppContainers. 

In my testing with separate Authz contexts: 

• The package SID ACE granted access to the matching package but not to a different package. 
• The capability SID ACE granted access to either package when the capability was included and enabled. 
• A different package possessing the same capability could therefore match the capability SID ACE but not the original package SID ACE. 

This also explains why both ACEs can provide the same tested rights to the current process when its token contains both SIDs. 

The distinction can be tested by using AuthzSetAppContainerInformation to create Authz contexts with different package and capability combinations, and then evaluating each descriptor with AuthzAccessCheck, as shown in the test. 

This demonstrates that the two ACEs have different authorization scopes. However, it does not determine which ACE Microsoft intended for the affected CBS/WebView2 resources. 

3. What documented approach should be used to determine the intended Windows-managed ACL state and assess LPAC-specific restrictions without modifying package files or their security descriptors? 

I could not find a documented public API that derives the intended ACL for an installed Microsoft-managed resource from its package identity, process token, neighboring files, or current security descriptor. 

The before-and-after ACLs can be preserved and compared, but neither one can be identified as the intended state solely from local Authz testing. In particular, matching results for the current processes do not show that the replacement ACE has the same authorization scope for other AppContainers. 

For the LPAC question, TokenIsLessPrivilegedAppContainer is listed in the current TOKEN_INFORMATION_CLASS documentation. However, the reported GetTokenInformation calls failed with ERROR_INVALID_PARAMETER. Because those calls failed, the unchanged output buffer and ReturnLength values do not provide valid token information. 

The test therefore does not establish whether the inspected tokens are LPAC tokens. I could not find a documented alternative that conclusively determines the LPAC status of an existing token when this query fails. Inferring LPAC status from the executable, its capabilities, or the expected component configuration would not be equivalent to querying the actual token. 

If there is evidence of component-store or protected-file corruption, the supported non-manual approach is to use Windows servicing and system-file repair mechanisms, such as DISM and System File Checker. The package files and their security descriptors should not be modified manually. 

However, the public servicing documentation does not establish that these tools can identify which of the two observed ACL snapshots is intended for these specific resources and Windows build. 

A definitive determination of the intended ACL for these Windows-managed resources, any LPAC-specific restrictions, and whether CRITICAL_ACE_FLAG has additional product-specific significance is not something I can independently provide through this forum. My findings are limited to the public documentation and the behavior I could test. 

If you require an authoritative answer for this Windows build, I recommend opening a case through Microsoft Support for Business, where the appropriate product team can review the affected resources and the before-and-after descriptors. If you do not have a business support plan, you can contact Microsoft Support instead. 

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation. Thank you.