Re: Passing the PCAP file descriptor to another

[Guy Harris <guy () alum mit edu>]

Sebastien Raveau wrote:

> I'm currently trying to pass the file descriptor of a live capture to another 
> process, so that I can have a very small (as in "auditable") privileged 
> process able to call pcap_open_live() on the one hand, and a big/fat/ugly/gui 
> process on the other hand running all the packet-analysis logic unprivileged 
> but able to start/stop captures by asking the privileged process...
>
> The FD passing works very well, but once I have the FD on the other process' 
> side, it's quite tricky to get Libpcap working:
>
> *       first I have to include the pcap-int.h file in order to be able to mess
>         with Libpcap's internals, starting with pcap_t::fd, and as you (may not)
>         know this file never gets installed in /usr/include :)

...because libpcap's internals are subject to change from release to 
release.

> *       then there's not much I can do with it: running unprivileged, my only
>         options are to call pcap_open_dead() or pcap_open_offline(),

...neither of which can handle live capturing (as pcap_open_dead() 
explicitly opens a "dead" pcap_t to work around the fact that 
pcap_compile() takes a pcap_t *, rather than a linktype and a snapshot 
length, as an argument, and as pcap_open_offline() assumes it's reading 
from a file).

> So, in order for PCAP-file-descriptor-passing-between-processes to be usable 
> (as in "deployed software") it appears that the only way would be to add 
> support for it directly in Libpcap, and I was hoping we could discuss "how 
> exactly" on this mailing list before I start implementing it :)

pcap_fdopen_live()?

One problem with that, however, is that, on at least some platforms, not 
all file descriptors from libpcap are the same.  On Linux, for example, 
with top-of-CVS-tree libpcap, the file descriptor could refer to:

        a PF_PACKET socket (the most common case);

	a DAG device (if you have a version of libpcap built with DAG support 
and have a DAG card and the corresponding software);

	a Septel/Intel/whoever Intel sold that group to card for SS7, if you 
have it and the corresponding software;

        a Bluetooth socket;

        a USB sysfs file.

This means that more information than is available from a file 
descriptor might be necessary in order to construct a pcap_t.

That might even be the case if it's known that, for example, the FD 
corresponds to the most common case on a given platform.

The way we'll probably end up handling this in Wireshark is to have the 
(potentially-)privileged program not only open the device but open the 
output file and write to it (after permanently relinquishing its 
privileges), with Wireshark reading the file based on information sent 
to it from the capture program over a pipe (that mechanism is already 
there - we just don't have the privilege separation there).  That won't 
necessarily work for your program, as it might not be oriented towards 
always having a capture file (Wireshark is, as it has to support random 
access to packets in the capture, even if the entire capture file won't 
fit into the process's address space).
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.