Ulf Lamping wrote:
Hi List!
While looking at the current capture handling and the recent command
line problems, I'm asking myself if it would be a good idea to split the
capture-child into it's own (little) program.
Yes. I thought that was the intent, as per the discussion in
http://wiki.ethereal.com/Development/PrivilegeSeparation
In addition, we do a lot of stuff for the capture-child we don't need to
do (which takes time and memory): register the dissectors (and need
memory for all of them), register plugins, and a lot more.
...such as dissecting packets, which is the source of most if not all of
the security problems in Ethereal; if the capture child doesn't do that,
and it's the only part that runs with elevated privileges on those
UN*Xes that require elevated privileges for capturing, the dissectors at
least can't get elevated privileges.
I see some real advantages to have a separate capture-child application:
- a small stand-alone capture application without all the Ethereal
dissection overhead, but with fine things like the ringbuffer feature
...and perhaps usable as a quick stand-alone capture program
independently from Ethereal.
- don't need to init a lot of unrequired stuff (dissectors, plugins,
...) for a capture start
- elevated privileges only required in the smaller and easier-to-audit
capture application
- main loop of Ethereal doesn't have to include waiting on the capture
device, which is somewhat tricky (e.g., GTK+'s/GLib's main loop uses
poll() on UN*X, but BPF devices aren't supported by poll() in Mac OS X
10.4[.x] - they're only supported by select(), and even that has the
annoying problem found at least in older versions of other BSDs that
require a timeout in the select). Pipes support select() and poll(); on
Windows, you can *probably* do a WaitForMultipleEvents() to select on
them (the GLib/GTK+ main loop uses WaitForMultipleEvents() or
MsgWaitForMultipleEvents() on Windows).
- we might be able to drop the requirement of GTK completely for the
capture child (when the capture info window isn't needed)
Do the capture window stuff in the main program, and have the capture
child just send packet counts on a pipe (or shared memory?) to the main
program. Note that GTK+ refuses to run set-UID (because you can crack
set-UID GTK+ programs by getting it to load *your* code in theme
engines, etc.).
And some disadvantages:
...
- probably security problems?
Actually, the simple capture child will probably have *fewer* security
problems, as per the above.