microsoft / microsoft/ebpf-for-windows

Add support for ALE reauthorization for hard permit

Open
#4,632 0 comments 0 reactions 1 assignee Claimed by @andrwli View on GitHub
enhancement P2 triaged
Dominant language
C
Stars
3.6k
Forks
311
Avg merge
6d 10h
Merged PRs (30d)
21

Description

Support for hard permit in the connect hook will be introduced via https://github.com/microsoft/ebpf-for-windows/pull/4558. However, during ALE reauthorization, if the verdict is hard permit, the classify callout will still return soft permit:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1672 [4]2030.1574::2025/09/04-14:50:50.240010600 [NetEbpfExtProvider]{"message":"connect_redirect_classify","transport_endpoint_handle":8495332,"protocol":6,"source_ip":"0.0.0.0","source_port":52918,"destination_ip":"192.168.16.1","destination_port":2003,"redirected_ip":"192.168.16.1","redirected_port":4555,"verdict":2,"compartment_id":0,"meta":{"provider":"NetEbpfExtProvider","event":"NetEbpfExtSockAddrRedirect","time":"2025-09-04T21:50:50.2400106Z","cpu":4,"pid":8240,"tid":5492,"channel":11,"level":4,"keywords":"0x20"}}
1684 [4]2030.1574::2025/09/04-14:50:50.240017400 [Microsoft.Windows.Networking.WFP.Callout]{"CorrelationId":3344692,"TransportEndpointHandle":8495332,"CalloutId":298,"Protocol":6,"Action":"Permit","ActionRights":"None","IsReauth":false,"meta":{"provider":"Microsoft.Windows.Networking.WFP.Callout","event":"ConnectRedirectClassify","time":"2025-09-04T21:50:50.2400174Z","cpu":4,"pid":8240,"tid":5492,"channel":11,"level":5,"keywords":"0x4"}}
1690 [4]2030.1574::2025/09/04-14:50:50.240100700 [NetEbpfExtProvider]{"Message":"_net_ebpf_ext_find_and_remove_connection_context_locked: Delete","value":8495332,"meta":{"provider":"NetEbpfExtProvider","event":"NetEbpfExtGenericMessage","time":"2025-09-04T21:50:50.2401007Z","cpu":4,"pid":8240,"tid":5492,"channel":11,"level":5,"keywords":"0x20"}}
1691 [4]2030.1574::2025/09/04-14:50:50.240101500 [NetEbpfExtProvider]{"message":"auth_classify","transport_endpoint_handle":8495332,"protocol":6,"source_ip":"192.168.17.10","source_port":52918,"destination_ip":"192.168.16.1","destination_port":2003,"verdict":2,"compartment_id":0,"meta":{"provider":"NetEbpfExtProvider","event":"NetEbpfExtSockAddrClassify","time":"2025-09-04T21:50:50.2401015Z","cpu":4,"pid":8240,"tid":5492,"channel":11,"level":4,"keywords":"0x20"}}
1700 [4]2030.1574::2025/09/04-14:50:50.240147800 [NetEbpfExtProvider]{"message":"auth_classify","transport_endpoint_handle":8495332,"protocol":6,"source_ip":"192.168.17.10","source_port":52918,"destination_ip":"192.168.16.1","destination_port":4555,"verdict":2,"compartment_id":0,"meta":{"provider":"NetEbpfExtProvider","event":"NetEbpfExtSockAddrClassify","time":"2025-09-04T21:50:50.2401478Z","cpu":4,"pid":8240,"tid":5492,"channel":11,"level":4,"keywords":"0x20"}}
1702 [4]2030.1574::2025/09/04-14:50:50.240150300 [Microsoft.Windows.Networking.WFP.Callout]{"CorrelationId":3344692,"TransportEndpointHandle":8495332,"ConnectionType":"RemoteProxy","Protocol":6,"OriginalRemoteAddress.Length":16,"OriginalRemoteAddress":"192.168.16.1:2003","RedirectedRemoteAddress.Length":16,"RedirectedRemoteAddress":"192.168.16.1:4555","CurrentRemoteAddress.Length":16,"CurrentRemoteAddress":"192.168.16.1:4555","OriginalLocalAddress.Length":0,"OriginalLocalAddress":"0x","RedirectedLocalAddress.Length":0,"RedirectedLocalAddress":"0x","CurrentLocalAddress.Length":16,"CurrentLocalAddress":"192.168.17.10:52918","NTSTATUS":"0x0(NT=STATUS_SUCCESS)","meta":{"provider":"Microsoft.Windows.Networking.WFP.Callout","event":"RedirectedAuthConnect","time":"2025-09-04T21:50:50.2401503Z","cpu":4,"pid":8240,"tid":5492,"channel":11,"level":3,"keywords":"0x4"}}
1822 [1]0004.025C::2025/09/04-14:51:12.330696700 [NetEbpfExtProvider]{"message":"auth_classify","transport_endpoint_handle":8495332,"protocol":6,"source_ip":"192.168.17.10","source_port":52918,"destination_ip":"192.168.16.1","destination_port":2003,"verdict":1,"compartment_id":0,"meta":{"provider":"NetEbpfExtProvider","event":"NetEbpfExtSockAddrClassify","time":"2025-09-04T21:51:12.3306967Z","cpu":1,"pid":4,"tid":604,"channel":11,"level":4,"keywords":"0x20"}}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Testing and documentation suggest that during ALE reauthorization, only the `FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V{4|6}` and `FWPM_LAYER_ALE_AUTH_CONNECT_V{4|6}` layers are typically reevaluated. [^1] This complicates simply re-invoking the eBPF program to determine if a verdict is a soft or hard permit. For instance, if the program redirects a `connect()` call, the reauthorization process will evaluate the redirected connection, which cannot be directly passed to the eBPF program. An alternative is to cache the connection verdict and tie it to the ALE flow’s lifecycle, since reauthorization merely revalidates permissions of an ALE flow. [^2] However, managing the lifecycle of such cache entries poses its own challenges.

[^1]:There is a scenario where the FWPM_LAYER_ALE_AUTH_CONNECT_REDIRECT_V{4|6} layers are reevaluated if the FWPS_CLASSIFY_FLAG_REAUTHORIZE_IF_MODIFIED_BY_OTHERS flag is set. https://learn.microsoft.com/en-us/windows-hardware/drivers/network/using-bind-or-connect-redirection
[^2]:https://learn.microsoft.com/en-us/windows/win32/fwp/ale-re-authorization

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.