HCS HvSocketServiceConfig — Do BindSecurityDescriptor and ConnectSecurityDescriptor enforce per-process AF_HYPERV access control for host and guest processes?

Question

I am evaluating the security boundary of Hyper-V sockets (AF_HYPERV) on Windows for a locally hosted, security-sensitive application.

The design requires OS-enforced endpoint access control, independently of application-layer authentication. A protected broker or mutual TLS authentication alone is insufficient if an unauthorized process can still perform a direct socket bind or connect operation.

Microsoft's HCS JSON schema documents the following properties under HvSocketServiceConfig:

• BindSecurityDescriptor

ConnectSecurityDescriptor

The schema describes security descriptors for host-process bind and connect operations. I would appreciate clarification from a Microsoft Hyper-V/HCS engineer on the supported enforcement model.

Questions

Supported compute systems: Which HCS-managed compute-system types support these properties in practice? Are they supported for Windows guest VMs, containers, or both? What are the applicable host/guest versions?

Evaluated security principal: For each descriptor, which Windows security token is evaluated (primary token, impersonation token, or another identity)? Which access rights and security objects participate in the access check?

Guest-process restrictions: Do these descriptors enforce any restrictions on guest processes attempting AF_HYPERV bind/connect operations, or are they exclusively host-side controls? If host-only, is there a documented and supported mechanism to prevent a restricted guest worker from opening its own Hyper-V socket independently of a protected guest supervisor?

Endpoint ownership: Do these controls prevent unauthorized competing listeners, endpoint squatting, duplicate binds, or bypass through wildcard VMIDs/ServiceIDs? How do service-specific descriptors interact with wildcard security policy?

Least-privilege host receiver: Can an already provisioned HCS socket service be bound to or used by a nonadministrator host process without granting Hyper-V management or service-registration privileges? What minimum rights are required?

Revocation and existing operations: When a descriptor changes, what happens to existing connections, inherited or duplicated socket handles, and outstanding operations? Are the new restrictions enforced only on subsequent bind/connect attempts?

Effective-policy verification: Is there a supported API or diagnostic procedure to inspect the effective security descriptor and verify which principal is permitted or denied for a particular service?

VMMS versus HCS: Can these HCS descriptors be applied through a supported interface to an ordinary VMMS-managed Hyper-V VM, or is their use limited to compute systems managed through HCS?

Required security property

The critical requirement is that Windows itself deny an unauthorized process's direct AF_HYPERV operation, rather than relying solely on a trusted broker to reject the resulting application message.

I am not asking whether TLS, Named Pipe ACLs, WDAC, or restricted tokens can protect other aspects of the application. I need to establish whether they—or the HCS descriptor mechanism—provide a supported, enforceable boundary for the relevant Hyper-V socket operations.

If any requested restriction is unsupported, please identify that explicitly. If it is supported, a Microsoft documentation reference, applicable API, security-object scope, or supported configuration example would be very helpful.

Microsoft documentation reviewed

https://learn.microsoft.com/en-us/virtualization/api/hcs/schemareference#hvsocketserviceconfig

https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/make-integration-service

https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/msvm-guestcommunicationservicesettingdata

Thank you for any authoritative clarification on the supported HCS/Hyper-V socket security model.I am evaluating the security boundary of Hyper-V sockets (AF_HYPERV) on Windows for a locally hosted, security-sensitive application.

The design requires OS-enforced endpoint access control, independently of application-layer authentication. A protected broker or mutual TLS authentication alone is insufficient if an unauthorized process can still perform a direct socket bind or connect operation.

Microsoft's HCS JSON schema documents the following properties under HvSocketServiceConfig:

BindSecurityDescriptor

ConnectSecurityDescriptor

The schema describes security descriptors for host-process bind and connect operations. I would appreciate clarification from a Microsoft Hyper-V/HCS engineer on the supported enforcement model.

Questions

Supported compute systems: Which HCS-managed compute-system types support these properties in practice? Are they supported for Windows guest VMs, containers, or both? What are the applicable host/guest versions?

Evaluated security principal: For each descriptor, which Windows security token is evaluated (primary token, impersonation token, or another identity)? Which access rights and security objects participate in the access check?

Guest-process restrictions: Do these descriptors enforce any restrictions on guest processes attempting AF_HYPERV bind/connect operations, or are they exclusively host-side controls? If host-only, is there a documented and supported mechanism to prevent a restricted guest worker from opening its own Hyper-V socket independently of a protected guest supervisor?

Endpoint ownership: Do these controls prevent unauthorized competing listeners, endpoint squatting, duplicate binds, or bypass through wildcard VMIDs/ServiceIDs? How do service-specific descriptors interact with wildcard security policy?

Least-privilege host receiver: Can an already provisioned HCS socket service be bound to or used by a nonadministrator host process without granting Hyper-V management or service-registration privileges? What minimum rights are required?

Revocation and existing operations: When a descriptor changes, what happens to existing connections, inherited or duplicated socket handles, and outstanding operations? Are the new restrictions enforced only on subsequent bind/connect attempts?

Effective-policy verification: Is there a supported API or diagnostic procedure to inspect the effective security descriptor and verify which principal is permitted or denied for a particular service?

VMMS versus HCS: Can these HCS descriptors be applied through a supported interface to an ordinary VMMS-managed Hyper-V VM, or is their use limited to compute systems managed through HCS?

Required security property

The critical requirement is that Windows itself deny an unauthorized process's direct AF_HYPERV operation, rather than relying solely on a trusted broker to reject the resulting application message.

I am not asking whether TLS, Named Pipe ACLs, WDAC, or restricted tokens can protect other aspects of the application. I need to establish whether they—or the HCS descriptor mechanism—provide a supported, enforceable boundary for the relevant Hyper-V socket operations.

If any requested restriction is unsupported, please identify that explicitly. If it is supported, a Microsoft documentation reference, applicable API, security-object scope, or supported configuration example would be very helpful.

Microsoft documentation reviewed

https://learn.microsoft.com/en-us/virtualization/api/hcs/schemareference#hvsocketserviceconfig

https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/make-integration-service

https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/msvm-guestcommunicationservicesettingdata

Thank you for any authoritative clarification on the supported HCS/Hyper-V socket security model.

Answer 1

BindSecurityDescriptor and ConnectSecurityDescriptor provide documented checks only for host-process bind and connect attempts on an HCS-managed compute system; they do not establish the required per-process access-control boundary inside a guest or for an ordinary VMMS-managed Hyper-V VM.

What is documented

The HCS schema defines:

• BindSecurityDescriptor: an SDDL descriptor checked before a host process binds to the specified service.
• ConnectSecurityDescriptor: an SDDL descriptor checked before a host process connects to the specified service.
• If omitted, the corresponding system default applies.
• AllowWildcardBinds separately enables wildcard processing; wildcard binds are secured through ...\Virtualization\HvSocket\WildcardDescriptors. ^1^

The schema exposes HvSocketSystemConfig through both VirtualMachine_HvSocket and Container_HvSocket. That proves configuration-model availability for HCS VM and container documents, but it does not provide a practical support matrix by container isolation mode, guest type, or Windows build.

Relevant version boundaries are separate:

• The descriptor fields entered the HCS schema in version 2.0.
• The documented HCS API applies to Windows 10 October 2018 Update, Windows Server 2019/2022, and the listed Azure Stack releases. ^2^
• HcsCreateComputeSystem has a documented minimum of Windows 10 version 1809 or Windows Server 2019. ^3^
• General Hyper-V socket support is broader: Windows 10/Windows Server 2016 or later hosts and Windows, Windows Server, or supported Linux guests. This does not imply that every such platform supports the HCS descriptors. ^4^

HCS-only configuration example

This is a partial schema fragment, intended to be placed under an HCS VirtualMachine.Devices.HvSocket.HvSocketConfig or container HvSocket configuration in a complete HcsCreateComputeSystem document:

{
  "HvSocketConfig": {
    "ServiceTable": {
      "11111111-2222-3333-4444-555555555555": {
        "BindSecurityDescriptor": "D:P(A;;FA;;;SY)(A;;FA;;;S-1-5-21-...-1001)",
        "ConnectSecurityDescriptor": "D:P(A;;FA;;;SY)(A;;FA;;;S-1-5-21-...-1001)",
        "AllowWildcardBinds": false
      }
    }
  }
}

Replace the example SID and Service GUID. FA is only an illustrative SDDL mask—not a documented minimum HvSocket right. Microsoft does not publicly document the HvSocket generic-rights mapping or the exact minimum access mask.

Provisioning requires an already authorized administrator or HCS controller. HcsCreateComputeSystem’s separate securityDescriptor parameter is reserved and must be NULL; it is not the HvSocket descriptor. ^3^

Unsupported or undocumented aspects

Question	Publicly documented result
Evaluated token	Not specified. The schema does not say whether HvSocket uses the process primary token, a thread impersonation token, or another captured identity. General AccessCheck behavior cannot establish HvSocket’s implementation choice.
Rights/security object	The SDDL check is documented, but its object type, generic mapping, requested access mask, and privilege interactions are not.
Guest processes	No guest-side enforcement is documented. The wording expressly says host process. There is no documented HCS mechanism here that prevents one guest process from independently binding or connecting.
Guest supervisor isolation	No supported per-process guest boundary is identified. Consequently, this mechanism cannot satisfy the stated requirement unless Microsoft supplies a separate supported guest-side control.
Endpoint squatting/duplicate binds	Normal successful-bind exclusivity should not be elevated into a security guarantee. Anti-squatting, duplicate-handle behavior, and descriptor interaction are not specified for AF_HYPERV. TCP/IP-specific SO_EXCLUSIVEADDRUSE documentation must not be assumed to apply.
Wildcards	Wildcards use the separately documented registry policy when enabled. Treat service-specific and wildcard authorization as distinct paths, but their precedence and complete interaction are undocumented.
Nonadministrator receiver	The schema suggests an allowed host identity can be represented in SDDL, but no documented minimum-rights recipe proves that this alone is sufficient for a nonadministrator receiver. Service registration itself is documented as an administrative operation. ^4^
Policy updates/revocation	Not specified for new attempts, connected sockets, pending operations, inherited handles, or duplicated handles. Do not assume either immediate or attempt-only enforcement.
Effective-policy query	No documented API returns the effective HvSocket descriptor or evaluates a principal against it. HCS has general property-query operations, but no documented property contract for effective HvSocket authorization. ^5^
Runtime modification	HcsModifyComputeSystem accepts schema-defined modification requests, but the public documentation does not identify a supported HvSocket resource path or version contract for updating these descriptors dynamically. ^6^
VMMS-managed VMs	No supported mapping is documented. VMMS WMI exposes a service GUID and enabled/disabled/deferred policy, not bind/connect descriptors. ^7^

Verification without overstating the guarantee

Behavior can be characterized on a specific build, but testing cannot create a supported contract:

1. Provision the HCS system as administrator with one allowed SID and one denied SID.
2. Run the same minimal AF_HYPERV test executable under each ordinary identity.
3. Test bind() and connect() separately and record the return value plus WSAGetLastError().
4. Repeat using a specific VM ID and every wildcard your design permits.
5. Test before and after any policy update, with existing connections and duplicated/inherited handles.

For conservative containment after a policy change, terminate application processes known to retain socket handles and stop/recreate the HCS compute-system instance. This is disruptive and is not a documented guarantee that all HvSocket handles are immediately revoked. HCS documents that stopping cleans up that compute-system instance and prevents further operations through its existing HCS handles; disk and application-data persistence depends on the surrounding configuration. ^2^

For the required security property, the defensible conclusion is: the public contract does not provide a supported OS-enforced guest per-process AF_HYPERV boundary, nor a documented way to apply these HCS descriptors to ordinary VMMS-managed VMs. A security design requiring either behavior needs written confirmation through Microsoft Support for the exact Windows builds and compute-system type, or must treat the requirement as unsupported.

---

References

1. JSON Schema Reference
2. Host Compute System Overview
3. HcsCreateComputeSystem
4. Make your own integration services | Microsoft Learn
5. Host Compute System API Reference
6. HcsModifyComputeSystem
7. Msvm_GuestCommunicationServiceSettingData class