Access control (Windows Filtering Platform)

In Windows Filtering Platform (WFP), the Base Filtering Engine (BFE) service implements the standard Windows access control model based on access tokens and security descriptors.

Access control model

Security descriptors can be specified when adding new WFP objects, such as filters and sub-layers. Security descriptors are managed using the WFP management functions Fwpm*GetSecurityInfo0 and Fwpm*SetSecurityInfo0, where * stands for the WFP object's name. These functions are semantically identical to the Windows GetSecurityInfo and SetSecurityInfo functions.

The default security descriptor for the filter engine (the root Engine object in the diagram below) is as follows.

• Grant GENERIC_ALL (GA) access rights to the built-in Administrators group.
• Grant GENERIC_READ (GR) GENERIC_WRITE (GW) GENERIC_EXECUTE (GX) access rights to network configuration operators.
• Grant GRGWGX access rights to the following service security identifiers (SSIDs): MpsSvc (Windows Firewall), NapAgent (Network Access Protection Agent), PolicyAgent (IPsec Policy Agent), RpcSs (Remote Procedure Call), and WdiServiceHost (Diagnostic Service Host).
• Grant FWPM_ACTRL_OPEN and FWPM_ACTRL_CLASSIFY to everyone. (These are WFP-specific access rights, described in table below.)

The remaining default security descriptors are derived through inheritance.

There are some access checks, such as for Fwpm*Add0, Fwpm*CreateEnumHandle0, Fwpm*SubscribeChanges0 function calls, that cannot be done at the individual object level. For these functions, there are container objects for each object type. For the standard object types (for example, providers, callouts, filters), the existing Fwpm*GetSecurityInfo0 and Fwpm*SetSecurityInfo0 functions are overloaded, such that a null GUID parameter identifies the associated container. For the other object types (for example, network events and IPsec security associations), there are explicit functions for managing the container's security information.

BFE supports automatic inheritance of Discretionary Access Control List (DACL) access control entries (ACEs). BFE does not support System Access Control List (SACL) ACEs. Objects inherit ACEs from their container. Containers inherit ACEs from the filter engine. The propagation paths are shown in the diagram below.

For the standard object types, BFE enforces all the generic and standard access rights. In addition, WFP defines the following specific access rights.

BFE skips all access checks for kernel-mode callers.

In order to prevent administrators from locking themselves out of BFE, members of the built-in administrators group are always granted FWPM_ACTRL_OPEN to the engine object. Thus, an administrator can regain access through the following steps.

• Enable the SE_TAKE_OWNERSHIP_NAME privilege.
• Call FwpmEngineOpen0. The call succeeds because the caller is a member of Built-in Administrators.
• Take ownership of the engine object. This succeeds because the caller has the SE_TAKE_OWNERSHIP_NAME privilege.
• Update the DACL. This succeeds because the owner always has WRITE_DAC access

Since BFE supports its own custom auditing, it does not generate generic object access audits. Thus, the SACL is ignored.

WFP Required Access Rights

The table below shows the access rights required by the WFP functions in order to access various filtering platform objects. The FwpmFilter* functions are listed as an example for accessing the standard objects. All the other functions that access standard objects follow the FwpmFilter* functions access model.

Related topics

• Standard Access Rights
• Windows access control model
• Windows Filtering Platform Access Rights Identifiers