Supported Windows IPC boundary for mutual application authentication under handle delegation

A named-pipe handle or connection PID must not be treated as continuing application authentication; use AppContainer/package identity to restrict initial access, then require fresh operation-bound authorization from a component the authorized endpoint cannot delegate or misuse.

Documented boundary of the pipe experiment

The observed result is consistent with documented handle semantics:

• Pipe handles can be duplicated into another, unrelated process and used there. Non-inheritability prevents inheritance during process creation; it does not prevent deliberate DuplicateHandle use.^1^
• DuplicateHandle produces a handle valid in the target process, provided the required PROCESS_DUP_HANDLE rights are available.^2^
• GetNamedPipeClientProcessId reports the client process identifier associated with the pipe instance; its contract does not say that it identifies the process performing every subsequent I/O operation.^3^
• A pipe DACL is checked when a client opens the pipe. A logon-SID ACE can exclude other logon sessions, but it does not cause a new access check on every write through an already granted or duplicated handle.^4^

Named-pipe impersonation similarly exposes the security context associated with the last message read; it authenticates a user/token context, not the executable currently holding a delegated handle. Failure must be checked before processing the request.^5^

Supported architecture for this threat model

Use two distinct controls rather than expecting one IPC primitive to supply both.

1. Package and isolate both endpoints. Run each endpoint in AppContainer or Win32 app isolation. An AppContainer token contains a package SID plus capability SIDs; access is the intersection of user/group and AppContainer grants.^6^
2. Restrict initial IPC acquisition. Put the current logon SID and the intended package/capability SID on the IPC object's DACL, grant only the required direction-specific rights, and reject remote connections. This excludes other users, sessions, and packages from opening the endpoint, but does not revoke authority after an authorized endpoint delegates it.
3. Authorize each operation. Bind approval to:
   • exact operation and parameters;
   • both expected package identities;
   • user/logon context;
   • server-generated nonce;
   • short expiry;
   • one-time consumption.
4. Keep approval authority outside the requesting endpoint. The signature or MAC must be issued by an isolated broker, trusted UI, service, or protected key holder that independently displays and approves the exact operation. If the authorized endpoint itself controls the credential, it can authenticate relayed requests; deliberate relay is then outside the guarantee.

A minimal request envelope is:

struct AuthorizedRequest {
    GUID operationId;
    std::vector<std::byte> canonicalParameters;
    std::array<std::byte, 32> serverNonce;
    uint64_t expiresAt;
    std::wstring callerPackageFamily;
    std::wstring calleePackageFamily;
    std::vector<std::byte> approvalSignature;
};
// Server verifies identities, nonce, expiry, signature, and one-time use
// immediately before executing the read-only operation.

AppContainer is a recognized isolation boundary and prevents lower-integrity container processes from injecting into higher-integrity processes; capabilities and DACLs provide least-privilege resource access.^7^ This is the primary same-user isolation control. Process mitigations are defense in depth, not caller authentication.

App Services: what is documented and unresolved

An App Service provider receives an AppServiceConnection, and activation details expose CallerPackageFamilyName; the provider can also test whether the caller has a declared capability.^8^^9^

The public contracts supplied here do not establish:

• whether connection authority can be marshaled into another process;
• whether caller package identity is revalidated per message;
• whether identity is fixed at activation or connection creation;
• whether an authorized caller may relay arbitrary requests;
• whether App Services support the exact cross-package desktop/AppContainer topology required here.

The Agile marshaling attribute on AppServiceConnection should not be interpreted as a cross-process security or non-transferability guarantee.^10^

Open a Microsoft developer support case before selecting App Services as the security boundary. Request written confirmation for those five points, including the targeted Windows build, packaging model, and whether identity/capability checks occur per request.

Package and signing identity

A package identity includes its name and certificate-derived Publisher; the Package Family Name derives from name and publisher and is version-independent.^11^ The manifest Publisher must match the signing certificate subject.^12^

Maintain an allowlist containing the expected PFN and publisher policy. Define update behavior explicitly: accepting the same PFN normally spans package versions, while publisher changes require a planned identity transition—not an implicit trust decision.

Verification matrix

Require these pass/fail results before deployment:

References

1. Anonymous Pipe Operations
2. DuplicateHandle function (handleapi.h)
3. GetNamedPipeClientProcessId function (winbase.h)
4. Named Pipe Security and Access Rights
5. ImpersonateNamedPipeClient function (namedpipeapi.h)
6. Launch an AppContainer
7. Application isolation
8. AppServiceTriggerDetails Class-Definition
9. AppServiceTriggerDetails.CheckCallerForCapabilityAsync(String) Method-Definition
10. AppServiceConnection Class-Definition
11. An overview of Package Identity in Windows apps
12. Create a certificate for package signing