ndo2db daemon should create its PID file before dropping privileges

[orlitzky]

Summary

The ndo2db daemon should create its PID file before dropping privileges. This represents a minor security issue; additional factors are needed to make it exploitable.

Description

The purpose of the PID file is to hold the PID of the running daemon, so that later it can be stopped, restarted, or otherwise signalled (many daemons reload their configurations in response to a SIGHUP). To fulfill that purpose, the contents of the PID file need to be trustworthy. If the PID file is writable by a non-root user, then he can replace its contents with the PID of a root process. Afterwards, any attempt to signal the PID contained in the PID file will instead signal a root process chosen by the non-root user (a vulnerability).

This is commonly exploitable by init scripts that are run as root and which blindly trust the contents of their PID files. If one daemon flushes its cache in response to SIGUSR2 and another daemon drops all connections in response to SIGUSR2, it is not hard to imagine a denial-of-service by the user of the first daemon against the second.

Exploitation

There is only a risk of exploitation when some other user relies on the data in the PID file. But you have to wonder, what's the point of the PID file if not to provide the PID to other people? Any situation where the PID file is used is therefore suspicious.

The init scripts that ship with ndoutils (in the startup) directory themselves rely on the PID file to reload the configuration.

[hedenface]

Current development branch of ndo-3 no longer has this issue, as there is no additional daemon running. If you'd like to help us test out (keep in mind this is NOT ready for production) - please let me know so we can facilitate that.