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 about 10 years ago. Updated about 5 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 about 10 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 about 10 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 about 10 years ago

# Daemon working directory

section in suricata.yaml

Actions

Copy link

Updated by Andreas Herz about 10 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 about 10 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 about 10 years ago

What are the permissions of /tmp ?

Actions

Copy link

Updated by Andreas Herz about 10 years ago

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

Actions

Copy link

Updated by Peter Manev about 10 years ago

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

Actions

Copy link

Updated by Andreas Herz about 10 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 about 10 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 about 10 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