Re: [ Process Information proposal + doubts on Capture Permissions ]

[Ashish Raste <rasteashish () gmail com>]

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 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<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