Wireshark · Wireshark-dev: Re: [Wireshark-dev] D-Bus support

["ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>]

Remotely (potentially across a network) starting and stopping a capture, i.e. doing remote captures would be very very useful and often requested feature.

However, this should probably not be implemented in wireshark and friends but rather in the libpcap/wiretap layer.


For any remote capture mechanism it would be absolutely nessecary to protect the interface with proper authentication and possibly privacy as well.
Does D-BUS provide something like GSSAPI integration with kerberos authentication  and per packet signatures to verify integrity?



I think the ideal solution would be a daemon/wrapper around tcpdump/dumpcap   that can be controlled remotely.
This daemon would have to support GSSAPI with kerberos to provide security.    A remote capture implementation with anything less would be completely useless and impossible for most serious users to ever consider using.

Then one would need either support inside libpcap to be able to hook up to a remote daemon instead of a local nic and do this transparently to the application that calls libpcap.
This would likely require libpcap to start depending on a full blown gssapi and kerberos infrastructure and that would likely be a major and big change to libpcap.   it is unknown if it is worth it or desired to add this to libpcap, the libpcap people would know if it is worth it.   
Maybe a better solution is to implement an external support library to libpcap that implements all the security?
(plugins to pcap?)



Any solution with less than adequate authentication and authorization framework support are unlikely to become any more popular than any of the other, previous, failed attempts at implementing remote captures.

On 10/26/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:

frederic heem wrote:
> Hi,
> D-Bus support has been adding to wireshark.
> For those who are interested to know more about this feature, a README.dbus
> has been written.
> Any comments will be appreciated
> Cheers,
> Frederic Heem
>
>
Mentioning the bugzilla entry 1179 would be a good idea - not everyone
will have read it to follow the discussion.

Some thoughts about your bugzilla comments:

- A link to the d-bus projects homepage would be nice:
http://freedesktop.org/wiki/Software_2fdbus
- your initial patch was 2350 lines - your full patch 5794 lines! I had
a quick look which took me more than 15 minutes and I didn't get it all
(I don't know dbus and cmake) in that time. I don't know how you can
review this in 15 minutes (especially when you've not written the code).
A good inspection rate of a serious code review takes around 1h for 1000
lines of non commentary code (however, this value varies depending on
the author your reading). You've mentioned 15 minutes which seems *very*
optimistic.
- "Controlling wireshark through D-Bus" is just misleading. You're
controlling dumpcap (which is just a small part of Wireshark). I would
understand controlling Wireshark mean to be able to control e.g. the WS GUI.
- adding a lot of #ifdef's to the dumpcap code *will* make it less
secure in the long run - it reduces maintainability and therefore make
new bugs more likely
- "since decoding no longer needs root privileges, security is improved"
- great that you've also find out why I took *a lot of time* to create
dumpcap and use it by WS to improve security - but that's in no way
related to your d-bus changes.

BTW: Stating to improve security by adding a possibly remotely
accessible mechanism is the best joke I've seen for quite a while.

I've tried to be polite in the response to your first bugzilla entry -
to guide you the way making inclusion of your patch much more likely. In
the meantime reading your answers to it, I don't feel a lot motivation
to spend my free time to work on your patch any longer.

Just remember that you are talking to mostly volunteers spending their
free time to work on this project. And working on your own work is
certainly much more appealing than reviewing someone else's code for
inclusion - how nice and practical this addition may be ...

Regards, ULFL
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev