Re: RFC: a loadable plugin framework for external capture backends

[Denis Ovsienko <denis () ovsienko info>]

Thank you for posting an overview of the problem and the proposed
solution Robin.

There is an important point that Guy and Michael have already made a
few times in March in the pull request comments, and which has also
reemerged at least once in this thread.  Which is that a data interface
between libpcap and a plug-in seems to fit the problem space better
than a callable API.  Consider this paragraph:

[...]
> Worth noting about this use case, because it bears directly on the 
> security discussion below: the plugin needs *no elevated privileges
> at all*. The only resource it touches is a UNIX socket, over which it
> asks the grout daemon to start/stop a capture. Packets are then
> delivered through an ephemeral shared memory segment that the daemon
> owns. libpcap itself opens nothing privileged for this backend.
[...]

What is says is that libpcap would generally load a shared object and
use its callable API.  The latter in one specific plugin would
communicate with the remote end of a Unix socket using a protocol.
This approach would introduce disadvantages and risks that have already
been discussed in this thread, plus potentially ones that will take
time to manifest.

Consider if the interfaces were arranged as follows:

[libpcap]-[socket]-[plugin]-[callable API]-[external packet source]

Here the "socket" for the sake of argument could be a Unix domain socket
or a named pipe or the rpcap protocol or a System V IPC message queue,
let's for now not compare these alternatives in detail, but focus on
two key properties.  Which are that the "socket" has an ID and can
provide a bi-directional communication channel between two different
processes.

It could even be a pair of "sockets" (one for the control requests and
responses and another for the packets), or a socket and a ring buffer,
as you describe.  It could use a subset or a super-set or a new version
of the rpcap protocol, or its own protocol.  The plugin end of such a
"socket" could be a standalone process or a function in a larger
program.  These are secondary details.

Let's for the sake of argument say that plugins could create their
"sockets" in /var/run/libpcap/, then basename(3) would identify a
plug-in and every plug-in that managed to create a "socket" would
automatically have a unique ID/namespace.  Compare this to loading
pcap-foo1.so and pcap-foo2.so, each of which turns out to declare
namespace "foo".  But that's a secondary detail as well.

One key difference would be that from libpcap perspective the use of any
plugin through a socket would follow the same general logic as has been
implemented for network interface packet capture, which is an exchange
of messages between libpcap and the OS kernel:

libpcap (L): What is the list of you capture devices?
plugin (P): A, B and C.
L: I am going to capture on B.
P: Acknowledged.
L: And the capture parameters are as follows...
P: Acknowledged.
L: Start now.
P: packet 1, packet 2, packet 3, ...

Another key difference would be that besides the "socket" the two
processes would be mostly independent: neither of the two would need
to be aware of the callable API, any implementation details or even the
programming language of the other.

In this case each plugin would be able to crash, hang, run OOM, set and
trip setrlimit(2), configure, receive and handle signals, set timers and
atexit(3) handlers, override standard library calls, link with 3rd-party
libraries, experience/mitigate/fix its own vulnerabilities, elevate and
drop privileges, run containerised, under debugger/strace/profiler etc.
-- all entirely at its end of the "socket".  Which means in a way that
does not affect other plugins, libpcap (other that "socket"-related
error handling) or the process that uses libpcap.  The only increase in
the attack surface would be the "socket" protocol, as far as it seems
to me.

Also, as mentioned in the pull request, each plug-in would be free to
decide how many threads and processes to involve, which could make it
easier to filter packets at high rate before these reach the plug-in
end of the "socket".  This would align with libpcap design, which is to
discard as many unwanted packets as early as possible.

However, the current design does not pursuit the goal of capturing all
packets at high rates -- there are other solutions for that, which
typically use specialised hardware and software.  libpcap can consume
multiple packets in one go under right conditions, but then it always
processes one packet at a time, and improving that aspect could be a
separate future development.

-- 
    Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s