tcpdump mailing list archives
Re: RFC: a loadable plugin framework for external capture backends
From: Guy Harris <gharris () sonic net>
Date: Thu, 1 Oct 2026 15:42:36 -0700
On Oct 1, 2026, at 2:53 PM, Robin Jarry via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
Michael Richardson, Oct 01, 2026 at 22:33:- Failure behaviour. A plugin that is missing, unloadable, or reports a mismatched ABI version must be a silent no-op, never a fatal error for libpcap or its callers.I agree that it shouldn't call exit(2)! I also agree that error strings need to be returned, not fprintf(stderr,..). I'm not understanding the no-op :-)The plugin loader could get an error back and optionally log it via strerror(). But since applications using libpcap are supposed to not care about plugins, they should not be affected if one of them is broken.
I.e., if tcpdump or dumpcap starts using libpcap, a failed plugin (missing, version mismatch, etc.) just results in the type of interface it supports not being supported.
4. The attack surface ===================== This is the part that most needs the group's judgement, and we do not want to hand-wave it. The honest position is that dlopen()ing code into a process that may hold capture privileges increases the attack surface, and the framework must be built so that the increase is as close to zero as possible.Thanks. I'd like _tcpdump_ to drop any privilege if it is told to load a plugin.
I'd like tcpdump - and dumpcap, and snort, and... - to hold as few elevated privileges as possible, ideally *none*. Npcap works that way, as I understand it. To open a device, it runs a small program with administrative privileges (which results in a UAT prompt), and that small program opens the NPF device (which requires Administrator privileges if Npcap is installed to require that) and then hands the HANDLE for it to the invoking program via some Windows API that I don't remember offhand. The UN*X equivalent would probably involve handing a file descriptor over a UNIX-domain socket. That, however, requires some mechanism to authorize elevating the program's privilege or to authorize that program to hand out descriptors. I am not sure what the right way is to do that; I think the UN*X equivalent of the Npcap solution would be to run the program with sudo/doas/some GUI equivalent, and if you get to sudo/whatever the program, you get to capture. _______________________________________________ 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
Current thread:
- Re: RFC: a loadable plugin framework for external capture backends, (continued)
- Re: RFC: a loadable plugin framework for external capture backends Denis Ovsienko (Oct 09)
- Re: RFC: a loadable plugin framework for external capture backends Michael Richardson (Oct 09)
- Re: RFC: a loadable plugin framework for external capture backends Michael Richardson (Oct 01)
- Re: RFC: a loadable plugin framework for external capture backends Vadim Goncharov (Oct 01)
- Re: RFC: a loadable plugin framework for external capture backends Stephen Hemminger via tcpdump-workers (Oct 01)
- Re: RFC: a loadable plugin framework for external capture backends Michael Richardson (Oct 02)
- Re: RFC: a loadable plugin framework for external capture backends Guy Harris (Oct 02)
- Re: RFC: a loadable plugin framework for external capture backends Vadim Goncharov (Oct 02)
- Re: RFC: a loadable plugin framework for external capture backends Guy Harris (Oct 02)
- Re: RFC: a loadable plugin framework for external capture backends Vadim Goncharov (Oct 01)
- Re: RFC: a loadable plugin framework for external capture backends Guy Harris (Oct 01)
- Re: RFC: a loadable plugin framework for external capture backends Stephen Hemminger via tcpdump-workers (Oct 01)
- Re: RFC: a loadable plugin framework for external capture backends Michael Richardson (Oct 02)
- Re: RFC: a loadable plugin framework for external capture backends Guy Harris (Oct 02)
- Re: RFC: a loadable plugin framework for external capture backends Robin Jarry via tcpdump-workers (Oct 03)
- Re: RFC: a loadable plugin framework for external capture backends Guy Harris (Oct 03)
- Re: RFC: a loadable plugin framework for external capture backends Robin Jarry via tcpdump-workers (Oct 04)
- Message not available
- Re: RFC: a loadable plugin framework for external capture backends Guy Harris (Oct 04)
- Re: RFC: a loadable plugin framework for external capture backends Robin Jarry via tcpdump-workers (Oct 05)
- Message not available
- Re: RFC: a loadable plugin framework for external capture backends Michael Richardson (Oct 09)
