Bug #1271: Creating core dump with dropped privileges - Suricata - Open Information Security Foundation

Actions

Copy link

Bug #1271

closed

Creating core dump with dropped privileges

Added by Andreas Herz over 9 years ago. Updated over 4 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Jason Ish

Target version:

5.0rc1

Affected Versions:

Effort:

Difficulty:

Label:

Description

I'm not sure if it's a bug or just a normal behaviour, but if i use another user for suricata (suri:suri for example) instead of root, i get

10/9/2014 -- 10:41:07 - <Info> - Core dump size is unlimited.
10/9/2014 -- 10:41:07 - <Info> - dropped the caps for main thread

So i guess with dropping the caps it looses the possibility to create a coredump. When i use root as user, it works.

Actions

Copy link

Updated by Peter Manev over 9 years ago

Can you confirm that this is not related to permissions?
Example - the user "suricata" has no permissions to write in the coredump directory defined in suricata.yaml?

thanks

Actions

Copy link

Updated by Andreas Herz over 9 years ago

Peter Manev wrote:

Can you confirm that this is not related to permissions?
Example - the user "suricata" has no permissions to write in the coredump directory defined in suricata.yaml?

How can i set the dir in the .yaml? couldn't find any documentation related to this.
I have the following in /etc/sysctl.conf and loaded it (for testing purpose):

kernel.core_pattern = /var/log/suricata/core_%e_%p_%s_%t

Since the folder is owned by suricata and it can write the logfiles (fast.log etc.) i doubt a permission issue.

Actions

Copy link

Updated by Peter Manev over 9 years ago

# Daemon working directory

section in suricata.yaml

Actions

Copy link

Updated by Andreas Herz over 9 years ago

Nothing defined, since it's not run in -D mode :)

Config is found here: http://paste.geekosphere.org/ZqatQTf8XLm6dRya (except that for the cap test the user part is changed from root to suricata and group as well)

Actions

Copy link

Updated by Andreas Herz over 9 years ago

Not sure if it's directly related but i have the same issue with the pidfile.

suricata -c /etc/suricata/suricata-eth4.conf -q 0 --pidfile /tmp/suricata-eth4.pid

When i have user "root" in the .conf i get the pid file created and deleted after suricata quits.
When i have another user like "suricata" i get the pid file created but not deleted after suricata quits.

I start suricata as "root" user in the shell (or via script), so i let suricata drop the privileges.

Actions

Copy link

Updated by Peter Manev over 9 years ago

What are the permissions of /tmp ?

Actions

Copy link

Updated by Andreas Herz over 9 years ago

drwxrwxrwt   3 root root  27K Nov  6 09:12 tmp

Actions

Copy link

Updated by Peter Manev over 9 years ago

Is that the case only when you use " -q 0 " ?

Actions

Copy link

Updated by Andreas Herz over 9 years ago

Also with just "-i ethX" the pidfile is not deleted. In "-D" mode i can't say it for sure, since sending "kill -s TERM" is resulting in "Signal Received. Stopping engine." but doesn't stop suricata, it keeps running.

Actions

Copy link

#10

Updated by Peter Manev over 9 years ago

For testing coredump - can you try:

sudo kill -n ABRT `pidof suricata`

instead of kill -s TERM

On a separate note.
If there is no traffic coming on to the listening interface Suricata will not exit - as you describe. Can you confirm this is the case - when you stop Suricata there is no traffic on the interface?

thanks

Actions

Copy link

#11

Updated by Andreas Herz over 9 years ago

Using ABRT results in suricata being stopped but no coredump file and the pidfile not removed.
I tested it with and without traffic, behaviour didn't change.

If i start suricata without "-D" like this:

/usr/sbin/suricata -c /etc/suricata/suricata-eth4.conf -i eth4 --pidfile /tmp/suricata-test.pid

And after engine is started and i press CTRL+c i'm also stuck at the signal received/stopping engine part, even as root:root without dropping privileges.

Actions

Copy link

#12