Hank Leininger wrote:
The other day, I wanted to run wireshark live, i.e. capture and view
some packets, rather than just feed it an existing pcap. On Linux, I
found this was basically impossible (longtime users probably know this
already):
- By default no part of wireshark is installed setuid
- There is an --enable-setuid-install configure option, which installs
both wireshark and dumpcap setuid root
- However, as mentioned in the docs, gtk apps don't like running as
root. And besides, this just seemed dumb.
- So, too, did actually being root to run (all of) wireshark.
- I tried chmod +s'ing only dumpcap. This gives it the needed privs,
_but_ it creates a tempfile with which to communicate with wireshark
that is mode 600 -- so when it runs as root, the rest of wireshark
cannot read the file.
While on a plane back home I whipped up the attached patch to dumpcap to
drop elevated privileges as soon as the pcap socket has been opened.
Then I can create a 'sniffer' group, and chgrp sniffer, chmod 4110 the
dumpcap binary. Tested for a whole five minutes, seems to work fine:
wireshark launches dumpcap to sniff, opens the raw capture socket, drops
root, opens the output file, and starts reading/writing packets. It
looks to me like every time a new capture is started, dumpcap is
respawned, so euid0 is not needed again. Works with tshark as well.
At the time, I had not yet read the discussions on the wireshark lists
(and the ethereal ones years before that) about how privilege separation
would be a better way to go, and about how the dissectors would best run
not just non-root, but non-user either--that is, they should run as a
dedicated, chrooted user. I agree that that would be ideal. But in the
meantime, I think something like this would be better than nothing.
Hi Hank!
I've spend a lot of time to carve out dumpcap into it's own process, to
make things you've explained actually possible. Please note that the
Wireshark/dumpcap combination misses some things like the capture live
list and alike, which currently will call pcap functions directly.
"Getting the capture interface specific infos" should go into dumpcap as
well, or a new process "capifinfo" or alike to avoid privilege problems
on this task.
As I'm a Win32 developer, I won't tweak the UNIX specific things and
need help from other UNIX developers. Unfortunately, NONE of the UNIX
developer found the time / motivation to spend some time on this topic.
So basically I've dropped my effort on this completely, as I found no
assistance to this - only complains "when will it be finished" - which
is not really motivating in itself ...
BTW: your patch will break Win32 compatibility, as setgid and alike
doesn't exist on Win32 (and probably not on all UNIX derivates we
support as well) - a simple #ifndef _WIN32 will solve this (for WIN32,
but probably not for other UNIXes).
Regards, ULFL
P.S: This motivation might change when I'll start working on Vista, as
"User Account Control" is basically the same thing. However, the switch
to Vista might take some time ...
