Suricata

I would like to create and work on two, extra but related issues which are:

1. Change owner of unix domain socket before priviledge drop
2. Change owner of file extraction dir before priviledge drop

Any objections? There are perhaps more related issues.

Richard Sailer wrote:

Richard Sailer wrote:

I would like to create and work on two extra but related issues which are:

1. Change owner of unix domain socket before priviledge drop
2. Change owner of file extraction dir before priviledge drop

Any objections? There are perhaps more related issues.

No objections here. With respect to the warning if permissions won't allow a re-open, I think I'd also want to the exit with --init-errors-fatal.

Also, in such cases we should see about moving the first open to a point after the privileges are dropped, so it fails out on first startup, rather than after a log rotate.

What do you think about simply changing the owner of the log dir and files to the user we will become,
just before the privilege drop?

This would be a simpler implementation than testing+warning, and nicer/less work for the admin.

Richard Sailer wrote:

What do you think about simply changing the owner of the log dir and files to the user we will become,
just before the privilege drop?

While I like this idea, I wonder what package maintainers, in particular for Fedora/Centos and Debian/Ubuntu would think of that.

This would be a simpler implementation than testing+warning, and nicer/less work for the admin.

While it might be nicer, would it still be worthwhile to do this for the case when not running as root? Might give us better error messages if we don't have write access to the log directory. For example, on FreeBSD/OpenBSD I believe non-root usage can be done just by tweaking the privileges on the /dev/bpf devices. So there you could have Suricata running as a user that can run in live mode, but not log?