Mark Pizzolato schrieb:
On Tuesday, February 08, 2005 at 12:53 AM, Ulf Lamping wrote:
Stephen Samuel (leave the email alone) wrote:
I realize that the code may not be all that big, but when
deciding policies, my backup thought is 'what would happen if
*everybody* did this?" Besides, if it adds capabilities for
non-priveledged processes, some people might consider this to
be a security issue.
That's the important point IMHO.
An administrator might not want users to capture from the network (for
whatever reason), so it should not enable this feature "accidentially"
as a default option.
Well, for all currently running Ethereal installations on windows,
essentially everyone has been "enabling this feature accidentally" the
first time anyone runs ethereal as an administrator. Almost no one
realized this first invocation of ethereal caused the NPF driver to load
and to be left running.
Ultimately WinPcap should be enhanced to handle device permissioning
better.
Meanwhile, if an administrator wants to achieve privilege separation on
Windows (a very good thing), the best choice is to auto load NPF.
Making this choice at install time would seem generally appropriate.
I found an interesting tool that comes with WinPcap.
For administrators wanting to achieve privilege separation for ethereal
and to have NPF driver loaded only when necessary, look at this:
C:\Programme\WinPcap>npf_mgm.exe /?
NPF Management - Written by Gianluca Varenni (varenni@xxxxxxxxx)
syntax: npf_mgm -s -x -u -i -r -a -d
-s starts NPF driver
-x stops NPF driver
-u uninstalls NPF driver
-i installs NPF driver
-r uninstalls and reinstalls NPF driver
-a changes the NPF driver start-type to auto-start
-d changes the NPF driver start-type to demand-start
Using "runas" with this tool, you can load the NPF driver just before
starting ethereal, and unload it when you don't need it anymore.
Regards,
Lars
