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.
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.
Note The Fwpm*SetSecurityInfo0 functions cannot be called from within an explicit transaction.
Note The Fwpm*SetSecurityInfo0 functions can only be called from within a dynamic session if they are being used to manage a dynamic object created within the same session.
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.
|WFP Access Right||Description|
Required to add an object to a container.
Required to create an association to an object. For example, to add a filter that references a callout, the caller must have ADD_LINK access to the callout.
Required to begin an explicit read transaction.
Required to begin an explicit write transaction.
Required to classify against a user-mode layer.
Required to enumerate the objects in a container. However, the enumerator only returns objects to which the caller has FWPM_ACTRL_READ access.
Required to open a session with BFE.
Required to read an object's properties.
Required to read statistics.
Required to subscribe for notifications. Subscribers will only receive notifications for objects to which they have FWPM_ACTRL_READ access.
Required to set engine options.
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.
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.
|Function||Object Checked||Access Required|
|FwpmTransactionBegin0||Engine||FWPM_ACTRL_BEGIN_READ_TXN & FWPM_ACTRL_BEGIN_WRITE_TXN|
|IPsecGetStatistics0||IPsec SA DB||FWPM_ACTRL_READ_STATS|
|IPsecSaContextCreate0||IPsec SA DB||FWPM_ACTRL_ADD|
|IPsecSaContextDeleteById0||IPsec SA DB||DELETE|
|IPsecSaContextGetById0||IPsec SA DB||FWPM_ACTRL_READ|
|IPsecSaContextCreateEnumHandle0||IPsec SA DB||FWPM_ACTRL_ENUM & FWPM_ACTRL_READ|
|IkeextGetStatistics0||IKE SA DB||FWPM_ACTRL_READ_STATS|
|IkeextSaDeleteById0||IKE SA DB||DELETE|
|IkeextSaGetById0||IKE SA DB||FWPM_ACTRL_READ|
|IkeextSaCreateEnumHandle0||IKE SA DB||FWPM_ACTRL_ENUM & FWPM_ACTRL_READ|
|FwpmIPsecTunnelAdd0||No additional access checks beyond those for the individual filters and provider contexts|
- Standard Access Rights
- Windows Access Control Model
- Windows Filtering Platform Access Rights Identifiers
Build date: 11/16/2013