microsoft / microsoft/ebpf-for-windows
Add support for ALE reauthorization for hard permit
- 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
Assessment
This issue has not been assessed yet.