npcap icon indicating copy to clipboard operation
npcap copied to clipboard

Add separate devices to open if only some interface information is desired?

Open guyharris opened this issue 5 years ago • 2 comments

If the driver supported an additional set of per-adapter devices that:

  • never require administrator access to open;
  • do not support capturing or injecting packets;
  • do support a small set of ioctls, such as BIOCQUERYOID, with either a whitelist of OIDs or a blacklist of OIDs if necessary, and the BIOCGNUMTIMESTAMPMODES and BIOCGTIMESTAMPMODES ioctls proposed in #174;
  • skip all the initialization that change b657dbcf9ef5925c352e1ca39cc23dd475bad7a1 was added to avoid;

that routine could be used to:

  • quickly check whether a given device name exists in the adapter-enumeration code, without having to worry about a UAC prompt popping up;
  • get the list of supported time stamp types without having to worry about a UAC prompt popping up (so that a GUI sniffer could have a combo box for the supported time stamp types);
  • determine the list of supported link-layer types, and whether monitor mode is supported, without having to worry about a UAC prompt popping up (for the same reason).

guyharris avatar May 25 '20 06:05 guyharris

Very interesting idea. Some parts of this have been implemented already, other parts require enhancements that are already planned in other issues, and I think there are some unique ideas here as well.

  • "never require administrator access" - Currently, all access to Npcap's exported device (\Device\NPCAP) is controlled with SDDL for Device Objects, a subset that is not very fine-grained. The default SDDL string is defined here, overridden for Admin-only mode here, and applied in IoCreateDeviceSecure() here. We are hoping to be able to store and retrieve ACLs for individual adapters, applying them to the Npcap device namespace in NPF_OpenAdapter(), which would allow us to do things like support read-only IoControl codes for all users but restrict capture or injection to any security principal that can be described by a SID (user, group, domain group, role, etc.). The issue for this enhancement is #96.
  • "skip all the initialization" - Npcap 0.9995 wraps up the final bugs in the "NPF_EnableOps" implementation, which puts off initializing things like registering the WFP callouts for loopback capture and querying WiFi adapters for their data rate mapping table. We may move other things to this function like allocating some objects and initializing spin locks, but these are very minor and fast operations already. Most importantly, in the OpenAttached (default) state, an instance will not process any network traffic.
  • "support a small set of ioctls" - We added a hasty implementation in Npcap 0.9995 of a "impossible to capture/inject from" device which is not exposed via Packet.dll, but which is intended to be used to get some general config info. You can see the change here, though a couple bugs were ironed out in later commits.
  • "quickly check whether a given device name exists" - Since access control is currently defined by the SDDL mentioned above, I would be interested to know if calling CreateFile() with dwDesiredAccess set to zero would allow checking the existence of an adapter without allowing Read, Write, or IoControls (which are defined as requiring basic read/write access). I think this would be possible to do in Packet.dll without requiring any driver changes. Since Packet.dll is responsible for invoking NpcapHelper.exe and thereby the UAC prompt, this might eliminate the UAC prompt for device listing.
  • "get the list/determine the list [...] without [...] UAC" - These operations would have to be coded into the IoControl code as not requiring any particular access (CTL_CODE with FILE_ANY_ACCESS. Right now we require FILE_READ_ACCESS for pretty much everything that isn't directly related to injecting packets; those require FILE_WRITE_ACCESS.

dmiller-nmap avatar Jul 14 '20 23:07 dmiller-nmap

Would it also be reasonable to have the "no administrator access required" device set the device mode to MODE_STAT, and reject attempts to change to MODE_CAPT with some form of "permission denied" error?

That would, for example, allow Wireshark's sparklines display to work without popping up any UAC prompts. (Wireshark should use MODE_STAT anyway, just to cut down the amount of work done by Npcap for the sparkline display. Then maybe I should nag the Linux developers and the developers for various OSes using BPF to have them provide an equivalent, to avoid the same extra work.)

guyharris avatar Feb 06 '22 07:02 guyharris