Wireshark mailing list archives
Re: [ Process Information proposal + doubts on Capture Permissions ]
From: Ashish Raste <rasteashish () gmail com>
Date: Fri, 3 May 2013 07:42:53 +0800
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 () pnnl gov> 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 () alum mit edu>To: Developer support list for Wireshark <wireshark-dev () wireshark org> Subject: Re: [Wireshark-dev] GSoC 2013 Project Proposal for Root permissions in wireshark Message-ID: <13FD8F47-197E-47A9-BD8A-C801E60E5B92 () alum mit edu> Content-Type: text/plain; charset=iso-8859-1 On Apr 25, 2013, at 7:26 AM, Surbhi Jain <jainsurbhi024 () gmail com> wrote:Would it mean that end user can also capture traffic which won't belongto 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<http://www.dickson.me.uk/2012/09/17/installing-wireshark-on-ubuntu-12-04-lts/>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
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: [ Process Information proposal + doubts on Capture Permissions ] Brandon Carpenter (May 02)
- Re: [ Process Information proposal + doubts on Capture Permissions ] Ashish Raste (May 02)