Add privilege support to Npcap so we can limit it to users with administrator access

[fyodor]

Right now, if the WinPcap (or Npcap) driver is running, any user on the system can sniff the network. We should consider what we can do to potentially restrict that to just administrator users. Just as how you need to be root on Unix in general to do this.

[hsluoyz]

I have investigated about how to add restrict the driver's access only to administrator users. And I'd like to know is the our access granted to the built-in Administrator account or all the members in Administrators group? Owing to User Account Control, it's not easy to implement the latter one. See my posts for more details: https://social.msdn.microsoft.com/Forums/en-US/05c94a06-b9bb-459b-9fe2-19cb8ecc66f6/iocreatedevicesecure-function-denies-the-access-from-member-in-administrators?forum=wdk

[hsluoyz]

It seems that we faced several plans for this.

Plan A: Allow Administrators group to use the driver, nmap run by built-in Administrator account can use the driver directly. The other members of Administrators group must run nmap with Run as Administrator option, or the driver will refuse to be accessed.

Plan B: Allow Users group to use the driver. All members of Users group can use the driver directly.

Plan C: Create a custom group named Nmap Users and add all Administrators group members into Nmap Users during NPcap installation, then allow Nmap Users group to access the driver. The drawback is if a new user added to Administrators group, there's no graceful ways to let that user join our Nmap Users group automatically. Admins need to add that user manually.

[hsluoyz]

As Plan B and Plan C are crossed out, we will only talk about Plan A here, depending on whether we really want to check the "true" administrator privilege, We have Plan A-1 and Plan A-2 as belows:

Plan A-1: Add access control to the driver, nmap run by built-in Administrator account can use the driver directly. The other members of Administrators group must run nmap with Run as Administrator option, or the driver will refuse to be accessed. When being denied, we can show our custom dialog to user which says like "You need to re-run the program as an Administrator to use NPcap, please restart your program as an Administrator". Notice Windows has no way to elevate a process during run-time, the Admin privilege is only granted when a process is started. So for this solution, Nmap MUST restart if not started with Run as Administrator option. Here what we can do as NPcap is that we prompt a customized error dialog then quit. Let the user restart a new Nmap by himself.

Plan A-2: We don't add access control to the driver, we only checks whether the current user is a member of Administrators group in our DLL (packet.dll). This solution has nothing to do with UAC and privilege elevation. So the current user do NOT have to run nmap withRun as Administratoroption. If the current user is a member of Admin group, then nmap can use NPcap normally, if the current user is not, we can prompt a customized dialog says "Your current account is not in Administrator group, please restart your program under an account within Administrator group.

To sum up, 1) Both solutions need to restart the program (such as Nmap) if the user fails our check. No way to elevate the privilege at run-time. 2) The difference between the two solutions is that Plan A-1 needs a "true" administrator privilege, so the not built-in members of Administrators group must run nmap with Run as Administrator option. Plan A-2 do not need a "true" administrator privilege, so all members of Administrators group can run nmap normally without Run as Administrator option.

Personally, I prefer Plan A-2, because this solution will give the end users less trouble. So there will be less complaints when user first adopts our NPcap. At the same time It's less safer than Plan A-1. What about your suggestions?

[hsluoyz]

I nearly finished this feature now, see http://seclists.org/nmap-dev/2015/q2/329