Feature #2931
open
Perform privdrop without libcap-ng support
Added by Emmanuel Roullit over 5 years ago.
Updated about 5 years ago.
Description
Some platforms might not have libcap-ng support which disables the "run-as" configuration option and leaves the user with no other options but to run suricata with elevated privileges.
We created a changeset which allows to drop privileges despite the lack of libcap-ng support.
It lets the main thread perform initialization with the needed elevated privileges and drops them, by using setresuid(2) and setresgid(2), right before the SuricataMainLoop() is entered.
There is a caveat, which has been documented in the changeset, RUNMODE_AFP_DEV requires elevated privileges to allow the packet acquisition threads to reopen an AF_PACKET socket.
To guard against this, suricata will not start and inform the user libcap-ng support is required when the following requirements are met:
- libcap-ng support is disabled
- uid or gid change requested
- RUNMODE_AFP_DEV main run mode detected
Does other runmodes such as RUNMODE_PFRING and RUNMODE_NAPATECH would require similar guard as well?
Related issues
1 (1 open — 0 closed)
- Related to Feature #276: Libcap support for dropping privileges added
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")
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.
Also available in: Atom
PDF