Wireshark · Wireshark-dev: Re: [Wireshark-dev] [ Process Information proposal + doubts on Capture Permissions ]

[Ashish Raste <rasteashish@xxxxxxxxx>]

Hi Brandon,

Thank you for sharing the HoNe project. My proposal is based on the very same idea by Fink et. al.

I was looking a feasible method to have libpcap to expose the information of a port/socket attached to a process, in the IP layer from the Transport layer as discussed in the paper. And I think with a module like hone_notify in the kernel, we can get that information.

Will go through your patch and PCAP_NG dissection thread, and get back to you soon.

Best,

On Fri, May 3, 2013 at 3:02 AM, Brandon Carpenter <hashstat@xxxxxxxx> wrote:

Ashish (and others interested in the process information proposal),

Please have a look at Hone:

https://github.com/HoneProject/

It is performing packet-process correlation on Linux with a Windows sensor soon to come.  We went through the trouble of determining that netstat, lsof, and other such tools are insufficient.  Hone inserts itself into the kernel to capture network and process events.  It is based on the research of Dr. Glenn Fink:

http://scholar.lib.vt.edu/theses/available/etd-08232006-203521/unrestricted/Final.pdf

The Hone Linux sensor consists of two modules: honeevent and hone_notify.  The honeevent module presents events from hone_notify as PCAP-NG output using a character device, /dev/hone.  The device uses standard permissions to control access allowing users to capture without elevating privileges.  It is possible for another module to use hone_notify to provide the same data in another form (e.g., via libpcap).  The hone_notify module can actually be broken into three modules that are responsible for process, connection, and packet events, with packet events being provided by netfilter.

I also took a swing at presenting the process information in Wireshark with this patch:

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8590

See also the discussion on the mailing list April 17 and 18 with the subject "Enhanced PCAP-NG dissection" regarding the patch.

I am very interested in this topic as it is the same thing I'm working on with Hone.  And I hope to continue working on getting this data into Wireshark.

Thanks,

Brandon

On 04/28/2013 09:09 AM, Ashish Raste wrote:

Hi Gerald, Guy and all developers,

Can you share your thoughts/suggestions on the proposal that I have submitted for Process Information(in the google-melange website) task? I think I need to do many revisions with the help of your suggestions before finalizing it.

From: Guy Harris <guy@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] GSoC 2013 Project Proposal for Root
        permissions     in wireshark
Message-ID: <13FD8F47-197E-47A9-BD8A-C801E60E5B92@xxxxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1


On Apr 25, 2013, at 7:26 AM, Surbhi Jain <jainsurbhi024@xxxxxxxxx> wrote:

> Would it mean that end user can also capture traffic which won't belong to him or if he is not the owner of the packet? Security has no concern for capturing packets?

If somebody's concerned about capturing "third-party" traffic not being sent by or to the machine running the sniffer, then:

        if the network is wired, they should require that they be able to control what software is installed on machines plugged into the network and ensure that it can't put an interface into promiscuous mode;

        if the network is wireless, they should use at least WPA/WPA2 encryption on the network;

so that only traffic to or from the machine running the sniffer can be seen un-encrypted.

If somebody's concerned about capturing traffic to or from the machine running the sniffer that's not being sent by or to a process running as the user running the sniffer, then they should only allow administrators to run sniffers.

If somebody's concerned about a user of a personal computer being able to capture traffic to or from their own machine, they should only allow administrators to run sniffers and not make the users of the PCs they provide to employees have administrative privileges.

There are already plenty of packet sniffers out there that, if they can capture traffic at all, can capture traffic regardless of who it's to or from on the machine.  This project is about giving users *full* Wireshark capabilities without requiring them to run as root; it's not about limiting Wireshark's capabilities so as to make it acceptable to run on machines on corporate networks so locked-down that they don't even want users to see what daemons are doing on their own machines.

I understand that by *full* Wireshark capabilities, you mean that a normal user should be able to listen on promiscuous as well as monitor mode(if it can be enabled for an OS). I don't know about Windows OS but at least in Ubuntu, we can set ourselves to a group, add wireshark to that group and grant capabilities to run wireshark by using setcap. So I think we can provide an option

asking whether you want the "User-mode" set and when an user marks it, we can carry out the setcap routines (please refer to this link to get my point).

Ah well, all these steps need "sudo" access. Now I get my naive thoughts. Your comments needed here :)

Any hint/suggestion to kick-off my ideas for this capture permissions work? It would be helpful for my Process Information task at later stages.

Thanks!

Best,

--

Ashish

--

Ashish