Npcap: use granular ACL to control access to capture/injection

Currently (Npcap 0.9984), Npcap can only control access to capture and inject at the device level, where the device is the special name and handle that the Npcap driver creates on the system, through which Packet.dll requests handles based on network interface name/GUID. In order to increase security, Npcap offers "Admin-only mode," which uses SDDL for Device Objects to restrict access to users with Builtin Admin privilege. This requires UAC elevation and applies to all Npcap functions on all interfaces. It is not possible to grant access to individual users or groups.

Instead of relying on device-level access control, Npcap could check the calling user's security identifier against a fully-featured ACL within the IRP_MJ_CREATE handler. This could enable us to do very specific access control like "Members of the Npcap Read domain group can do packet capture on these interfaces, but not packet injection."

Challenges:

1. Where and how should the ACL be stored? Probably the Registry, but need specifics and format.
2. How should system admins update or modify the ACLs? Probably a helper program, but it would be best to use existing Windows APIs and dialogs for identifying principals and editing ACEs.
3. Synchronization between Registry and running driver, avoiding race conditions.

Start by reviewing the Npcap driver’s IRP_MJ_CREATE handler and the current device-level access-control path. Investigate Registry storage, Windows APIs and dialogs for editing principals and ACEs, and synchronization with the running driver. Done means a specified granular ACL design covering capture, injection, interfaces, updates, and race avoidance.