On Monday, February 07, 2005 11:21 PM, Stephen Samuel wrote:
I kinda squirm at the thought of loading yet more code into windows
memory on boot, ehen it's not always used. I think that the best
approach would be to have it not loaded by default, but have it
still be an install-time option (for systems that use ethereal
rather often).
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.
Clearly someone installing Ethereal on a system needs to make this policy
decision.
It also should illuminate the same side effect that has always been here
(i.e. after the first time someone runs ethereal as a privilege user, the
NPF driver was loaded and available for ANY other program on the system to
run).
In any case, the idea of initially loading the NPF driver, removes any
requirement from ethereal to run with privilege and therefore inadvertently
be susceptible to the consequences of latent bugs in ethereal packet
dissecting code. This is a move in the right direction.
Until the Winpcap folks provide a better way to manage access to the NPF
device, this is the best we can do.
Lars Roland wrote:
Mark Pizzolato schrieb:
The ethereal windows installer could probably be offer an option to
enable the starting of NPF at system startup. 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.
I've checked in a change to the installer. The option to start the NPF
at system startup is disabled by default. Should it be enabled by
default?
I have no strong opinion about the default setting.
Take care to only offer the choice (or act on the selection) IF there is an
NPF driver installed(.i.e..HKLM\SYSTEM\CurrentControlSet\Services\NPF\Start
exists and is NOT (1 or 2) already).
- Mark Pizzolato
