Supported private-registry reference for an unchanged zero-capability LPAC caller

Question

Supported private-registry reference for an unchanged zero-capability LPAC caller

Spencer Wagemann 0

This is a documentation question about a proposed Windows desktop containment design. No deployed configuration or runtime behavior is asserted.

Does Microsoft support GetAppContainerRegistryLocation obtaining the caller's exact private registry root reference in a zero-capability Less-Privileged AppContainer, without forbidden mutation or effective write/subkey-creation authority?

TOKEN_INFORMATION_CLASS describes LPAC restrictions concerning ALL_APPLICATION_PACKAGES, while SECURITY_CAPABILITIES separates the AppContainer SID from its capability list. Does a supported, already-present package-SID authorization apply to the caller's private store in this case? If so, how does that reconcile with the Launch an AppContainer article's registryRead prerequisite? We are not proposing to add or change any grant.

Please identify authoritative documentation and applicable platform/API limits covering:

Zero-capability LPAC eligibility and the exact current user, package/AppContainer, private root/store and registry view, including architecture-dependent views.
Whether acquiring the reference can create, initialize or mutate anything, including when the expected storage is absent.
Why the acquired reference carries no effective write or subkey-creation authority. A KEY_READ request alone is insufficient: RegCreateKeyExW documents a parent security-descriptor check independent of its handle-acquisition mask.
Whether that reference supports a correctly targeted named-subkey denial operation without first obtaining forbidden authority.

The contract forbids a broker, inherited trusted handle, added capability, ACL exception, impersonation workaround, retry, fresh profile, broader root or weaker acceptance rule. Unexpected private-registry write authority or mutation is terminal before close/report.

If this supported contract is unavailable, please identify the incompatible or undocumented clause. A generic AppContainer example, proposed access grant or successful test would not establish the requested documented LPAC contract. Please provide documentary semantics, not instructions to execute or alter a machine.

0 comments

1 answer

Your answer

Answer 1

Hello @Spencer Wagemann ,

Thank you for clearly outlining the requirements and constraints of the proposed design.

I checked the published Win32 documentation for the contract you described. Based on that documentation, I cannot verify the complete contract for an unchanged, zero-capability LPAC.

For the four points you listed:

GetAppContainerRegistryLocation says that the returned HKEY identifies the registry storage location for the current profile. It also says that the function gets registry storage for the current user and that accessing another user's storage requires impersonation. TOKEN_INFORMATION_CLASS and SECURITY_CAPABILITIES document the AppContainer SID and capability list separately. However, I could not find a statement that the package SID alone allows a zero-capability LPAC to open its private registry store. Launch an AppContainer states that “LPAC cannot open any keys in the registry unless it has the registryRead capability.” I could not find a documented exception for the LPAC's own private registry store. The general WOW64 documentation explains KEY_WOW64_32KEY and KEY_WOW64_64KEY. However, Accessing an Alternate Registry View does not list GetAppContainerRegistryLocation among the APIs for which those flags are documented. I therefore cannot establish the exact registry view returned by this API from the published documentation.
The documentation for GetAppContainerRegistryLocation does not say whether the function can create, initialize, or modify storage when the expected store is absent. CreateAppContainerProfile separately documents the creation of a per-user, per-app profile containing folders and registry storage. That tells me which API creates the profile, but it does not guarantee that GetAppContainerRegistryLocation has no side effects when the storage is absent.
RegCreateKeyExW confirms your concern about KEY_READ. It states that key-creation access is checked against the parent key's security descriptor, not the access mask used to obtain the handle. It also states that a handle obtained with KEY_READ may still be used to create keys if the security descriptor permits it. I could not find published documentation for the security descriptor or effective package-SID grants on the private registry root in this scenario. For that reason, I cannot use a KEY_READ request alone to establish that the returned reference has no effective subkey-creation authority.
I could not find documentation that defines or supports the named-subkey denial operation you described through a handle returned by GetAppContainerRegistryLocation. I also could not find a guarantee that such an operation can be performed without first obtaining any authority excluded by your contract.

In summary, I found documentation for the current-user/profile scope, the separation between the AppContainer SID and capabilities, the general LPAC registryRead requirement, and the security-descriptor check used for subkey creation. I did not find documentation for a private-store exception to registryRead, the exact registry view returned by this API, non-mutating behavior when storage is absent, the private root's effective creation rights, or the named-subkey denial semantics.

Because those points are not documented, I cannot confirm the complete contract as stated.

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

Thank you.