Suricata

Github PR available at https://github.com/OISF/suricata/pull/3793

I think a cleaner option would be to disable the whole reconnect/reopen feature in af-packet when we know it can't work. We can determine this at start up, so we might have a message at initialization of af-packet.

Agree with Victor on reconnect. It is really unlikely it happens on standard ethernet interface so we could disable it in this case.

But question, is there Linux distribution without libcap-ng available ?

Right now libcap-ng is not mandatory on Linux, so we need to think about how to handle the case where its not available. Perhaps we can simply make it mandatory for Linux.

I am not aware of a specific Linux distro having this situation. So test this case on my machine, I forced LIBCAP_NG to "no" like this:

diff --git a/configure.ac b/configure.ac
index 41e1b13..287fa43 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1711,7 +1711,7 @@
         LDFLAGS="${LDFLAGS}  -L${with_libcap_ng_libraries}" 
     fi

-    AC_CHECK_HEADER(cap-ng.h,,LIBCAP_NG="no")
+    AC_CHECK_HEADER(cap-ng.h,LIBCAP_NG="no",LIBCAP_NG="no")
     if test "$LIBCAP_NG" != "no"; then
         LIBCAP_NG="" 
         AC_CHECK_LIB(cap-ng,capng_clear,,LIBCAP_NG="no")

A v2 Pull request has been published: https://github.com/OISF/suricata/pull/3800

Out of curiosity: have you considered doing a libcap implementation or supporting libcap-ng on the platforms you care about?

Victor Julien wrote:

Out of curiosity: have you considered doing a libcap implementation or supporting libcap-ng on the platforms you care about?

I'm not sure if we'll seen libcap/libcap-ng on other platforms. OpenBSD has pledge support, so I wonder if thats good enough for them. Would be nice to know if FreeBSD has something as well that would be more preferred than this approach in the above PR.

It would be nice to have some resolution here. I'm not against a lowest common denominator approach that may be limited in what it can do.

For example, how far could we get without ever elevating privileges again? This is not something we'd have to worry about on Linux with libpcap-ng. The idea is to keep the lowest common denominator as simple as possible.