Mark Pizzolato wrote:
You post some interesting ideas for Window, however, they are far more
complicated than needed (i.e. the model of having a separate process
doing actual pcap activities and a separate non privilege display
process).
Winpcap actually ONLY needs privilege to "load the NPF driver". When
winpcap is installed, the NPF driver is configured to load "On
Demand", which means by the first user of an application which uses
winpcap. Privilege is needed to perform this load, but any
unprivileged application can use winpcap after the NPF driver is
initially loaded. .The act of loading the NPF driver can be done
automatically at system boot time by making a simple registry change
the details of which described at:
http://winpcap.polito.it/misc/faq.htm#Q-18
At least it's an interesting and good to know detail, but this won't
solve problems for other systems, and I would like to have a solution
for all. BTW: The new model *might* enable us later to do some other
interesting things (e.g. capturing from multiple interfaces at once).
The ethereal windows installer could probably be offer an option to
enable the starting of NPF at system startup.
That might be a good idea in any case.
This would completely solve privilege separation for Windows and avoid
the overhead of attempting to do these things in a separate process
and pass all data to a display process.
Well, what you might not know, is that it's already handled that way
when you do an "Update list of packets in Real-Time" capture! The
problem is, depending on the user settings, we will use one of both
possible ways, which makes the code very ugly (believe me, I'm working
now for several days on it and it's not very funny to be honest). So a
code cleanup here will bring us several advantages, privilege separation
is only being one of them.
Regards, ULFL
