Project

General

Profile

Actions

Feature #2931

open

Perform privdrop without libcap-ng support

Added by Emmanuel Roullit almost 5 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:

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 open0 closed)

Related to Suricata - Feature #276: Libcap support for dropping privilegesNewCommunity TicketActions
Actions #2

Updated by Victor Julien almost 5 years ago

  • Related to Feature #276: Libcap support for dropping privileges added
Actions #3

Updated by Victor Julien almost 5 years ago

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.

Actions #4

Updated by Eric Leblond almost 5 years ago

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 ?

Actions #5

Updated by Victor Julien almost 5 years ago

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.

Actions #6

Updated by Emmanuel Roullit almost 5 years ago

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")

Actions #7

Updated by Emmanuel Roullit almost 5 years ago

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

Actions #8

Updated by Victor Julien over 4 years ago

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

Actions #9

Updated by Jason Ish over 4 years ago

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.

Actions

Also available in: Atom PDF